Netmanias Report: IP Backbone Network
1999년 10월 19일
www.netmanias.com
손 장 우 (010-3460-5747, son@netmanias.com)

Classical IP over ATM over SONET/SDH (Overlay model): IP/AAL5/ATM/SONET/Optical
95년이후 인터넷이 상용화되면서 인터넷 트래픽의 급증으로 인해 1997년부터 상용 ISP 망에도
ATM/SONET이 사용되기 시작했다. Edge의 IP router들을 ATM PVC로 full mesh로 연결한 형태를 갖
는다. 이 당시 ATM이 백본에 적용된 이유는 다음과 같다.
- ATM이 OC-3 (155 Mbps), OC-12(622 Mbps)의 고속 링크를 지원했고 (기존의 라우터 기반
인터넷: 전용 회선 or FR~DS1, DS3, X.25~)
- Flexible bandwidth allocation (1.5Mbps ~ 600Mbps)
- 기존의 라우터상에서 동작하는 라우팅 프로토콜 (RIP, OSPF)이 망의 혼잡 상태에 상관없이 항
상 목적지로의 최단 경로를 선택하여 포워딩하므로 망 자원을 능률적으로(골고루) 사용하지 못
한다. 특정 지역(라우터, 링크)는 혼잡으로 패킷이 긴 지연과 큰 손실을 겪어도 특정 지역은 망
자원이 충분해도 패킷이 이 지역으로 라우팅되지 않는 문제를 지닌다. 반면에 ATM을 사용하면,
Edge router간에 ATM PVC를 설정할 때 망 전체에 부하가 균등히 퍼지도록 설정하여(보통,
manually) 망 자원을 효율적으로 사용하면서 동시에 패킷의 지연이 줄고 손실이 감소하는 효과
를 얻을 수 있다.
이 구조 (Classical IP over ATM over SONET: rfc 1483 [4], rfc 1557 [5])에서 각 Layer의 역할은 IP
layer는 IP packet routing, ATM layer는 flexible bandwidth allocation for virtual links, SONET layer는
SONET path level fault and performance management capability를 제공 등을 담당한다.  
그림 1. IP over ATM encapsulation
1Netmanias Report: IP Backbone Network
하여 잘 쓰다가, 인터넷 트래픽은 계속하여 급증하여 IP 백본 링크 전송율이 기가급으로 확대되자,
ISP들은 다음과 같은 몇 가지 측면에서 고민 및 문제에 부딪치게 된다. 첫번째는 ISP가 망 사업자
(Transport network provider)로부터 요금을 내고 빌려 쓰는 SONET 전송 링크 중 얼마만큼을 실질적인
유료 트래픽을 나르는 가에 대한 문제이다.
즉, 현재의 Classical IP/ATM/SONET solution에서는 링크 용량(SONET capacity)  중  네트워크
오버헤드-ATM cell tax-가 차지하는 비율이 실질적으로 매우 크다는 점이다. 언뜻 보기에는 ATM 헤더
오버헤드가 5Byte이고 페이로드가 48 바이트이므로  대략 10%정도의 대역폭이 네트워크 오버헤드로
버려지는 것처럼 보이지만 실제로 상용 ISP 백본망(MCI’s backbone OC-3 link, June 1997)에서 관측한
결과는 심각한 대역폭의 낭비를 입증해주었다.  
AAL5 frame: LLC(0xAA-AA-03:3B) + SNAP 헤더(0x00-00-00-08-00:5B) + IP packet (40B)+pad(0)
+ AAL5 CPCS-PDU trailer (8B) = 66B가 2 ATM AAL5 cell로 매핑, 66B/40B = 165.0%
(Table Source: Bell Lab. Technical Journal, Jan.-Mar.1999)
표 1에 1997년 6월 25일에 MCI 백본 OC-3 링크로부터 5분 동안(18*10
6
packets, 6.7 GB) 관측된 패
킷 사이즈의 분포가 나타나 있다. 40, 1500, 552, 44, 576 바이트의 5종류의 패킷이 주종을 이루었다
(총 패킷수 중 71.5%).
표 2에 위의 5 종류의 패킷에 대한, IP over SONET 구조의 네트워크 오버헤드(즉, PPP/HDLC의 프레
이밍 오버헤드)와 Classical IP over ATM (rfc 1483) 구조의 네트워크 오버헤드 (즉, ATM 오버헤드)가
비교되어 나타나 있다. IP over SONET 매핑이 오버헤드가 훨씬 적은 데 이는 IP datagram의 길이에 관
계없이 PPP/HDLC 오버헤드가 8 바이트로 일정하기 때문이다.
표 1에서 보듯이 인터넷 백본상의 IP datagram의 45%가 40바이트이거나 44 바이트이다. 이러한 IP
datagram은 하나의 ATM 셀에 담겨 지지 않으며 따라서 이 두 종류의 패킷에 관한한 IP over ATM  매
2Netmanias Report: IP Backbone Network
3
핑은 대단히 비효율적임을 알 수 있다.
표1의 5종류의 패킷에 대해 평균을 내보면 대략 25% 정도의 대역폭이 ATM 오버헤드로 낭비된다. 반면
에, 동일 패킷 분포에 대한 IP over SONET 매핑 구조의 PPP/HDLC tax는 약 2%정도에 지나지 않는다.
즉, 2.5 Gbps의 OC-48 링크중 ATM cell tax로 낭비되는 대역폭은 625 Mbps로 OC-12  링크하나분에
해당하며 PPP/HDLC tax로 낭비되는 대역폭은 50 Mbps로 DS-3 링크 하나분에 해당한다. 이와 같은 관
측에서 보면 현재와 같이 실 인터넷 트래픽이 기가급에 이른 상황에서 인터넷 백본에서 ATM을 사용하
는 경우 대단히 비효율적임을 알 수 있다.
두 번째 문제는 링크 전송율이 OC-48/192급으로 증가했을 때, 이 링크 속도를 지원하는 ATM AAL5
SAR기능의 구현이 지극히 복잡하고 어렵다는 점이다.
세 번째 문제는 현재 Classical IP/ATM/SONET solution에서 각 Edge router는 ATM PVC로 full-mesh
형태로 연결된다. 에지 라우터 (또는 POP)의 수가 증가하면 이 라우터들을 상호 연결해주기 위해 소요
되는 ATM PVC의 수가 O(N^2)으로 증가하여 IP 백본망의 확장에 한계가 있다는 점이다.
네 번째 문제는 Routing adjacency문제로 에지 라우터가 단일홉으로 다른 모든 에지 라우터와 ATM PVC
를 통해 연결되어 있으므로 하나의 라우터에 라우팅 정보가 갱신되면 다른 모든 라우터의 라우팅 정보가
갱신되어야 하는 데 여기에 소요되는 route update complexity가 O(N^3)으로 매우 복잡하고 라우팅 테
이블이 안정화되는 데 긴 시간이 소요된다.
고찰 포인트: ATM layer를 제거하면 ISP는 SONET 대역폭을 보다 효율적으로 사용할 수 있게 된다. 그
러나, ATM만이 제공해줄 수 있는 virtual link bandwidth에 대한 유연한 관리 능력을 상실하게  된다.IP
백본망에서는 이미 기가급의 링크가 사용되고 있고 이 링크를 채울 만큼 백본 트래픽이 급증하고 있으므
로 IPOS 구조가 바람직하고 Access Network에서는 트래픽의 aggregate rate이 작고 fluctuation이 심하
므로 IPOA 구조가 현재로서는 바람직하다고 생각된다.
IP directly over SONET/SDH (in short, POS or IPOS): IP/PPP/HDLC/SONET/Optical
기존의 Classical IP over ATM over SONET의 문제를 극복하기 위해 IP directly over SONET 구조가 제
시되고 있으며 현재 대부분의 벤더들의 제품이 이를 지원하고 있다. 즉, IP/PPP/HDLC/SONET 구조를
채택함으로써 ATM cell tax문제를 제거하여 높은 링크 효율을 얻을 수 있으며 OC-48, OC-192의 초고
속 링크의 지원이 Classical IP over ATM over SONET구조보다 훨씬 용이해진다.
IP directly over SONET 구조는 흔히 POS(Packet-over-SONET), IPOS(IP over SONET) 등으로 불리
워지며 실제 프로토콜 스택은 IP/(MPLS/)PPP/HDLC/SONET/Optical (orWDM)로 구성된다.
PPP (Point-to-Point Protocol[7]은 multi-protocol encapsulation,  error control, link initialization
control procedure 등의 기능을 제공한다)로 encapsulated된 datagram은 rfc 1662 [8]에서 기술된
HDLC-like framing 절차를 통해 프레임화되고 이 HDLC 프레임은 rcf 1619 [6]에서 기술된  방식으로 Netmanias Report: IP Backbone Network
바이트 단위로 SONET 프레임의 SPE (Synchronous Payload Envelope)로 매핑된다.  
IP datagram의 길이에 상관없이 8바이트 (F/1+A/1+C/1+Protocol/2+FCS/2+F/1)의 고정된
PPP/HDLC 오버헤드만 요구되므로 SONET 전송 대역폭을 매우 능률적으로 사용할 수 있음을 알 수 있
다.
앞 절에서 분석한 대로 IP directly over SONET구조는 IP packet을 전송하는 데 소요되는 네트워크 오버
헤드가 평균 2%정도로 매우 작다는 점과 AAL-5 SAR기능이 필요없으므로 초고속 링크에 적합하다는
장점으로 인해 선호되고 있으며, 현재 대부분의 벤더 제품(Avici, Charlotte, Pluris, Argon, Cisco,
Juniper, Lucent, Nortel)에서 POS OC3/12/48을 지원하고 있으며 Nexabit의 NB64000은 OC-192까지
지원된다.
그림 2. IP over SONET (POS)
F(Flag): 01111110, A(Address): 11111111, C(Control): 00000011  
FCS: Frame Check Sequence, IFF/NF: Inter Flame Fill or Next Frame Figure. IP directly over SONET encapsulation
PPP/HDLC 프레이밍 방식은 flag-based PDU delineation 방식으로 프레임 경계를 추출한다. 그림 에서
보이듯이 PPP/HDLC 프레임의 맨 앞과 맨 끝에 0x7E (0111 1110)의 Flag 바이트가 붙는다. 이  flag
byte를 인식함으로써 receiver는 수신 프레임의 경계를 추출할 수 있는 것이다. 여기서, 문제는 이 flag
pattern (0x7E)이 frame payload내의 user data내에서도 나타날 수 있다는 점이다. 실제  flag  byte와
user data내의 우연히 발생한 flag-pattern byte를 구별해주기 위해 escape sequence (0x7D)를 이용하는
escaping 기법을 쓴다. 즉, Transmitter는 프레임 페이로드내에 flag byte(0x7E)가 나오면 이 바이트를
(0x7D) (0x5E)로 바꿔 주고, (0x7D)가 나오면 이 바이트를 (0x7D)(0x5D)로 바꿔준 후 전송한다.  
4Netmanias Report: IP Backbone Network
Receiver에서는 이 stuffed pattern (0x7D) (0x5E), (0x7D)(0x5D)를 각각 (0x7E), (0x7D)로 바꾸어
original byte stream을 복원한다. Transmitter에서 전송할 데이터가 없는 경우에는 flag  byte를
연속적으로 전송한다.
이러한 바이트 단위의 프레세싱이 요구되는 escaping 기법으로 인해, transmitter와 receiver  모두
바이트 단위의 복잡한 pattern matching 과정을 수행해야 한다. 이로 인해 링크가 고속화되면 이 과정의
구현이 매우 복잡해지거나 불가능해진다.
또한 escaping 기법을 사용하는 이 PPP/HDLC 프레이밍 방식은 랜덤 비트 에러 발생시 전체 프레임이
날라갈 수 있다는 문제도 있다. 즉, frame payload내의 nonflag pattern byte에 전송 에러 (trasmission
error)가 발생하여 이 바이트가 flag byte로 둔갑하면 receiver에서는 이 바이트 수신후 현 프레임이 끝난
걸로 인식해 최소한 두 프레임이 날라가게 된다.  
또한 true flag byte에 비트 에러가 발생하여 연속적인 두 프레임을 하나의 프레임으로 인식하는 경우도
발생한다. (그래서, 대개 벤더들은 PDU가 길어지면 FCS-32를 쓴다.)
PPP/HDLC의 페이로드내의 비트 패턴에 따라 페이로드의 길이가 랜덤하게 늘어나므로 전송율 예약에
기반한 QoS 제어 미케니즘이 사용되는 경우 정확한 전송율을 유추해낼 수 없다는 문제도 있다.
최근에, 이러한 문제를 해결하기 위해 Lucent에서 Simplified Data Link (SDL) 프로토콜이  제시되어
많은 관심을 모으고 있으며 Lucent의 TDAT024G5 칩은 이 SDL 프로토콜을 지원한다.
현재 IP over SONET/SDH용으로 가용한 상용칩은 Lucent technology사의 TDAT024G5와 PMCSierra사의 PM5357이 있다. 양사의 제품이 모두 Line interface 기능, SONET / SDH 처리 기능, ATM
cell / Packet 처리 기능, System interface (Buffer간 데이터 전송 기능), Micro Processor interface
기능 등을 갖는다.
한 ATM만 걷어 내지 말고 SONET layer까지 없애고 바로 IP를 DWDM으로 매핑하는 IP over DWDM이
IP 백본망의 진화 단계상 궁극적인 구조로 제시되고 연구되고 있다.
5Netmanias Report: IP Backbone Network
6
참고문헌  
[1] Jon Anderson, James S. Manchester, Antonio Rodriguez-Morai, and Malathi Veeraraghavan,
\"Protocols and Architectures for IP Optical Networking,\" BLTJ, Jan.-Mar. 1999.  
[2] rfc 2702: Requirements for Traffic Engineering Over MPLS , September 1999  
[3] Chuck Semeria, \"Traffic Engineering for the New Public Network,\"  Juniper  white  paper,  Jan.  25
1999.  
[4] rfc 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5, July 1993  
[5] rfc 1557: Classical IP and ARP over ATM, January 1994  
[6] rfc 1619: PPP over SONET/SDH, May 1994  
[7] rfc 1661: The Point-to-Point Protocol (PPP), July 1994  
[8] rfc 1662: PPP in HDLC-like Framing, July 1994