공중 ATM망에서의 IP 전송기술 동향

고석주* 신명기** 김용진***

본 고에서는 ATM 기반 공중망에서 IP 전송기술 동향에 대하여 살펴본다. 특히 지난 '99년 9월 ITU-T SG13 회의에서 결정된 사항을 중심으로, 공중 ATM 망에서의 IP 망구조 및 IP 서비스 제공방안 등에 대하여 소개한다. ITU-T에서는 초고속 인터넷 서비스 전송과 서비스 품질 보장을 위한 IP over ATM 기술로써 MPLS(Multi-Protocol Label Switching) 기술을 채택하였으며, 향후에 보다 구체적인 MPLS 적용방안에 대해 표준화 작업을 추진할 예정이다. ▒

I. 서 론

인터넷 기반 통신망 및 응용서비스의 급격한 성장으로 인해 공중 ATM 망에서의 IP 서비스 전송 기술에 대한 표준화 요구가 증가하고 있다.

그동안 사설 ATM 망에서의 IP 서비스 전송기술로써 C-IPOA(Classical IP over ATM)[11], MPOA (Multi-Protocol Over ATM)[6] 및 MPLS(Multi-Protocol Label Switching)[17, 18] 기술들이 제안되어 왔다.

먼저 IETF에서는 AAL5, LLC/SNAP[7] 및 ATM ARP(Address Resolution Protocol) 기술을 토대로 하나의 LIS(Logical IP Subnet) 안에서의 IP 전송 기술인 C-IPOA(Classical IP Over ATM) 표준을 제안하였고, ATM Forum에서는 LIS 내의 LANE (LAN Emulation) 기술과 LIS 간의 NHRP(Next Hop Resolution Protocol)[12] 기술 및 ATM Short-Cut 개념을 결합한 MPOA(Multi-Protocol Over ATM) 기술을 표준으로 제안하고 있다.

또한 최근에 IETF에서는 IP 라우팅 및 ATM 스위칭 기능을 결합한 MPLS 기술을 표준화 하고 있다. 특히 MPLS 기술은 기존 C-IPOA 및 MPOA 등의 계층적 모형(overlay model)이 대규모 망에서 갖는 확장성(scalability) 문제를 해결하기 위해 제안되었다. 즉, IP 라우팅 정보를 이용하여 IP 데이터의 전송경로를 결정하고, 결정된 경로를 따라 ATM 스위칭 기능을 이용하여 데이터를 전송하는 방식이다.

한편 ITU-T/SG13, Q.20 그룹에서는 공중 ATM망에 적합한 IP 데이터 전송 방식에 대한 표준화 작업이 진행중에 있으며[1], 이를 위해 먼저 기존에 제안되어 온 IPOA 해법들을 분석하고, ATM 망에서 전송될 수 있는 주요 IP 서비스를 정의한 다음, 각 정의된 IP 서비스에 따라 적절한 IPOA 해법을 권고하는 방식을 택하였다.

본 고에서는 먼저 공중망에서의 요구되는 IPOA 프레임워크(framework)를 살펴보고, ATM 망에서 주요 IP 서비스들을 제공할 수 있는 방안을 살펴본 다음, ITU-T에서 권고되는 공중망에서의 IPOA 해법에 대하여 기술하고자 한다.

II. 공중망에서의 IPOA 프레임워크

공중 IPOA 망의 프레임워크는 크게 망구조(network architecture)와 프로토콜 구조(protocol architecture) 부분으로 정의될 수 있다.

1. IPOA 망구조

(그림 1)은 공중망에서의 IPOA 망구조로 공중 ATM 망을 중심으로 여러 가지 다른 종류의 망이 라우터를 통해 연결될 수 있음을 보여준다. 공중 ATM 망은 기본적으로 순수 ATM 서비스를 제공하고 있으나, IP 서비스 제공을 위해서 IP over ATM 기능이 수행된다. 인터넷 사용자는 접속망, ISP(Internet Service Provider), 사설망 혹은 다른 도메인의 공중망 등을 통하여 대상이 되는 공중 ATM 코어 망에 진입할 수 있다. 대상이 되는 공중 IPOA 망과 여러 형태의 주변 망과의 연동은 경계 라우터에서 수행되어야 하며, 이에 대한 연구는 ITU-T에서 추후에 논의될 예정이다.

(그림 2)는 공중 및 사설 ATM 망에서 IP 서비스를 제공하기 위한 망구성(network configuration) 예제를 보여준다. 그림에서 보여주듯이 IP 서비스는 ATM의 스위칭 기능과 IP 서비스 기능(IPSF)을 통하여 제공된다. 이 경우 ATM과 IPSF와의 인터페이스는 ITU-T 권고안 I.364[3]에서 정의되는 P 혹은 M reference points로 정의될 수 있다. 여기에서 IPSF의 전형적인 예로는 IP와 ATM 간의 주소변환 서비스 등을 들 수 있다.

ATM 망 외부의 ISP 혹은 ES(End System)들은 Private UNI 혹은 Public UNI 등을 통하여 IPOA 망에 접속되며, ATM 망에 직접 접속하는 경우 각 ES들은 그 자체가 IPOA 프로토콜 스택을 가지고 있어야 한다.

2. IPOA 프로토콜 구조

(그림 3)은 공중 IPOA 망에서 IP 서비스 전송을 위한 일반적인 프로토콜 참조 모델을 보여준다. 이 모델에서 각 계층은 해당하는 계층관리(Layer Management) 기능블록과 연관되어 구현되고, 각 계층관리 기능블록은 자체의 PCI(Protocol Control Information)의 처리 및 관리 기능을 담당하게 된다. 각 계층간의 정보 교환은 망관리(Network Management) 기능을 통하여 이루어진다.

어떤 IPOA 네트워크 응용에 대해서는 일부 기능 블록들이 정의되지 않을 수도 있다. 따라서 위의 기능 블록들은 기본적인 기능 블록으로써의 의미가 강하다. 하지만 다른 기능 블록이 정의되는 경우에는 기능 블록간의 연동 및 상호운용성(inter-operability)이 유지되어야 한다.

위 그림에서 정의된 몇몇 주요 기능에 대해 기술하면 다음과 같다:

가. IP 계층 기능

IP 계층은 송신자에서 수신자에 이르기까지 IP 데이터그램 포워딩(forwarding) 기능을 제공한다. IP 포워딩은 패킷을 받았을 때, 해당 패킷이 어떻게 처리되어야 하는 지를 결정한다. 패킷은 자체 로컬에서 종료될 수도 있고, 외부로 전달될 수도 있다. 외부로 전달되는 트래픽에 대해서는 어떤 출력 포트 혹은 인터페이스로 보내져야 하는 지를 결정한다. IPOA 프로토콜 구조는 IP 버전(IPv4 혹은 IPv6)에 독립적이어야 한다. 또한 IP계층 기능은 수송계층의 TCP/UDP 기능 및 IP-SSCS/AAL5 기능과 독립적이어야 한다.

나. IP-SSCS/AAL5 계층 기능

이 계층은 IP 패킷을 AAL5 위로 매핑(mapping)하는 기능을 수행한다. 이를 위한 주요 기능으로는 LLC/SNAP Encapsulation[7] 등이 있다.

다. 망 관리 기능

망 관리 기능은 구체적인 IPOA 네트워크 응용에 따라 다르게 정의될 수 있지만, 일반적으로 Fault 관리, Performance 관리, Configuration 관리 및 보안관리 등을 포함한다.

라. 시그널링 및 라우팅 제어 기능

이 기능은 IP 및 ATM 제어에 필요한 모든 시그널링 및 라우팅 기능블록들을 포함한다.

이 외의 다른 주요 기능들은 다른 ITU-T 권고안에서 기술되고 있다.

III. ATM 망에서의 IP 서비스 제공

ITU-T 표준화 작업에서는 공중 ATM 망에서 IP 서비스 제공을 위해 먼저 두 가지의 IP 서비스를 중점적으로 고려하는데, QoS(Quality of Service) 지원 IP 서비스와 VPN(Virtual Private Network) 서비스가 그것이다. 이 외의 IP 서비스도 추후에 논의될 예정이다. 본 절에서는 공중 ATM 망에서 각 IP 서비스를 제공하기 위한 요구사항 및 고려사항에 대하여 기술한다.

1. QoS IP 서비스

IP 서비스의 품질 보장을 위해 지금까지 두 가지의 기술이 제안되어 왔다. 하나는 개별 IP flow에 대하여 QoS를 보장하기 위한 Integrated Services(이하 intserv) 방식이고, 또 하나는 개별 flow를 취합하여 QoS를 보장하기 위한 Differentiated Services(이하 diffserv) 방식이다.

Intserv 방식에서는 RSVP(Resource Reservation Protocol)[8]에 의해 전달되는 IP flow에 대한 QoS 요구사항을 충족시켜준다. 패킷이 전달되는 경로의 RSVP 라우터에서 승인제어 및 자원예약이 이루어진다. Intserv 방식에서는 GS(Guaranteed Service)[10] 및 CLS(Controlled-Load Service)[9] 등의 두 가지 QoS서비스가 정의되고 있으며, GS는 종단간의 최대 전송지연시간(maximum delay) 보장을 엄격히 요구하는 데에 비해서, CLS는 장기적으로 일정 수준 이상의 품질 보장을 요구한다. 두 가지 모두 토큰버킷(token bucket)[8] 규격에 따라 flow의 특성이 결정되며, 계약한 트래픽 규격을 초과하여 패킷이 망에 진입하는 경우 best-effort 트래픽으로 처리되도록 규정하고 있다.

Diffserv[13] 방식은 각 IP 패킷 헤더의 DSCP(DS codepoint) 필드에서 정의되는 PHB(Per Hop Behavior) 개념에 토대를 둔다. 일단 IPOA 망에 진입한 IP 패킷은 포워딩 및 버퍼 스케쥴링 등에서 자신의 PHB에 따라 취급을 받는다. 현재까지 두 가지 종류의 PHB가 정의되었다.

- EF(Expedited Forwarding) PHB[16]

- AF(Assured Forwarding) PHB[15]

가. QoS IP 서비스를 지원하기 위한 네트워크 모델

본 절은 IPOA 망에서 QoS IP 서비스를 지원하기 위한 네트워크 모델을 기술한다. 먼저 (그림 4)는 ATM 망에서 intserv를 지원하기 위한 네트워크 모델을 보여준다. 그림에서 종단간의 intserv 서비스가 IPOA 코어 망을 통해 제공되고 있다. 기본적으로 IPOA 코어 장비들은 intserv 및 diffserv를 동시에 지원할 수 있으나, 이 경우 단지 intserv 기능만 사용된다. 각 네트워크 사업자 사이의 SLA(Service Level Agreement)를 통해 필요한 트래픽 파라미터 매핑 및 flow 승인제어 정책 등이 협상될 수 있다.

(그림 5)는 ATM 망에서 diffserv를 지원하기 위한 네트워크 모델을 보여준다. IPOA 장비들은 intserv 및 diffserv를 동시에 지원할 수 있으나, 단지 diffserv 기능만 사용된다. 원활한 diffserv 제공을 위해서 각 네트워크 사업자들간에 SLA 협상이 요구된다.

(그림 6)은 단지 diffserv 만 지원되는 IPOA 망을 경유하여 intserv가 제공되는 시나리오에 대한 네트워크 모델을 보여준다. IPOA 백본망에서 intserv에 비해 diffserv가 보다 일반적으로 보급될 것이라는 전망에 의해 단지 diffserv 만 지원되는 IPOA 망이 존재할 수 있으며, 이 경우 종단간의 intserv flow는 터널링(tunneling) 기법을 통해 diffserv 영역을 통과하게 된다. 그림에서 SLA1과 SLA2는 서로 다른 형태의 SLA 임을 알 수 있다.

나. 서비스 매핑 기능

공중 ATM 망에서 QoS IP 서비스를 지원하기 위해 IP 서비스와 ATM 서비스간의 매핑이 필요하다. (그림 7)은 IPOA 망에서 가능한 매핑 목록을 보여준다. 이중 매핑 1, 2, 9, 11은 IP 서비스와 ATM Forum에서 정의된 ATM 서비스와의 매핑이며, 매핑 3, 4는 intserv와 diffserv와의 매핑으로 IETF에서의 고려될 것이다. ITU-T에서는 매핑 6과 12에 대해서만 다룬다. 한편 그림에서 매핑 5와 10은 ATM 망에서 IP서비스를 수용하는 측면에서 반드시 고려될 필요는 없다.

다. IP Intserv와 ATM 매핑

IP intserv 트래픽이 ATM 망에 도착할 때 서비스 및 QoS 매핑이 필요하며, 이러한 매핑은 다음의 요구사항을 충족해야 한다.

- 선택되는 ATC(ATM Transfer Capability)는 intserv의 지연시간 요구조건을 만족시켜야 한다.

- 또한 intserv flow의 트래픽 특성에 맞는 대역폭을 예약해야 한다.

ITU-T 권고안 I.371[5] 및 I.356[2]에 나와있는 ATC 및 QoS 클래스를 이용하여 <표 1>처럼 ATM 서비스를 정의할 수 있다. <표 1>과 같다.

<표 1>에서 DBR(Deterministic Bit Rate)은 ATM Forum의 CBR(Constant Bit Rate)과 유사하며, SBR(Statistical Bit Rate)은 VBR(Variable Bit Rate)과 유사하다. 한편, QoS 클래스 1은 엄격한 셀 지연(cell delay) 및 셀 손실(cell loss) 요구사항을 가지며, QoS 클래스 2, 3은 지연과 손실에 덜 민감한 서비스를 위해 개발되었다.

IP와 ATM 간의 매핑 관계는 구현 이슈이긴 하지만, 일반적으로 다음 사항을 고려하여 매핑 관계를 정할 수 있다.

- 먼저 DBR에 비해서 SBR ATC가 통계적 다중화 이득(statistical multiplexing gain)이 크므로 SBR ATC가 선호된다.

- 또한 SBR을 사용하는 경우, SBR3 ATC가 선호된다. SBR3만이 태깅 선택사항(tagging option)을 제공하며, 이는 초과 트래픽을 best-effort 트래픽으로 처리하도록’하는 intserv 요구사항을 만족시킬 수 있기 때문이다.

위의 사항을 고려할 때에 intserv/GS의 경우, 매우 엄격한 지연 요구사항을 가지므로, QoS 클래스 1을 갖는 SBR1 ATC가 선호된다. 또한 intserv/CLS의 경우, 지연 및 손실 요구 정도가 상대적으로 작으므로, SBR3 ATC가 선호된다. Intserv/GS를 SBR1으로 매핑하는 경우 태깅 선택사항을 적용할 수 없다. 이를 위해 ITU-T I.371의 수정 권고안 작업에서는 QoS 클래스 1과 거의 동일한 QoS 클래스 4를 정의하여 SBR3에서 지원될 수 있도록 하는 일을 추진 중에 있다. 이 경우, SBR3 ATC에 QoS 클래스 4를 intserv/GS에 매핑시킬 수 있다.

라. IP Diffserv와 ATM 매핑

IP diffserv의 경우, intserv와는 달리 ATM 서비스로의 매핑을 표준화하기 매우 어려운데, 그 이유는 다음과 같다:

- 표준 규격에서 IP diffserv는 최종 서비스가 아닌 PHB에 기초하여 정의되고 있다. PHB는 종단간의 서비스가 아닌 전송 경로상의 개별 라우터에서의 패킷 처리 행위를 규정하고 있다. 궁극적으로 diffserv PHB를 통해 최종 서비스가 현실화 되겠지만, IETF에서는 diffserv 서비스에 대한 정의를 내리지 않고 있다.

- IETF에서는 diffserv 서비스를 각 사업자 도메인의 에지(edge) 라우터에서 트래픽 컨디셔닝(traffic conditioning) 형태로 규정하도록 한다. 즉, 사업자와 고객사이의 협상 및 계약을 통해 diffserv 서비스가 현실화 되고, 이러한 협상을 토대로 각 패킷에 대해 PHB가 정의될 것이다.

사실상 IETF diffserv에서는 사업자가 자율적으로 서비스를 정의하도록 한다. 이것은 종단간에 서비스 연결(connection)을 정의하는 ATM과는 다른 개념이다. 따라서, diffserv 사업자가 명시적으로 서비스를 정의한 후에, ATM ATC와의 매핑 관계가 정의될 수 있다. 예를 들어, diffserv개념을 토대로 엄격한 자원예약을 요구하는’소위 프리미엄(premium) 서비스를 정의할 수 있으며, 이러한 서비스에 EF-PHB가 적용될 수 있다. 이 경우 ATM에서는 QoS 클래스 1을 갖는 DBR ATC를 이용해 프리미엄 서비스를 매핑할 수 있을 것이다.

2. IP VPN(Virtual Private Network) 서비스

ATM 망에서 제공될 수 있는 주요 IP 서비스로써, IP VPN [14] 서비스가 고려된다. 특히 VPN 서비스는 QoS 보장 및 멀티캐스트 요구사항을 가지며, 기업체 등의 대규모 인터넷 고객들에게 널리 사용될 것으로 전망되어, 차세대 인터넷에서 목표로 하는 응용서비스의 하나이다.

가. IP VPN 서비스의 정의

VPN은 그룹화된 여러 고객 사이트를 연결하여 주는 가상 LAN이다. 특히 IP VPN에서는 이러한 VPN을 통해 IP 서비스를 전송하게 된다. 각 고객 사이트는 자기가 속한 그룹 이 외의 다른 사이트와도 통신을 할 수 있다.

나. IP VPN 지원을 네트워크 모델

ATM 망에서 IP VPN서비스를 제공하기 위한 전형적인 네트워크 모델이 (그림 8)에 나와 있다. 그림에서 각 고객 사이트(CE)들은 ATM 망에서 논리적인 네트워크 연결을 갖는다.

다. IPOA 망에서 IP VPN 서비스 요구사항

IPOA 망에서 IP VPN서비스를 제공하기 위해서는 다음 요구사항을 만족시켜야 한다.

- Opaque 패킷 전송: VPN 사용자들은 다른 IP 사용자와 서로 독립적인(opaque) 패킷 전송을 주고 받아야 하며, 이는 VPN 고객들이 그들의 논리적 VPN 망에서 독립적인 IP 주소를 사용할 수 있도록 한다. 또한 이의 구현을 위해 VPN 멤버쉽 관리 및 VPN-ID 사용 등이 요구된다.

- 보안성: VPN 구현을 위해서는 데이터 전송에서 보안성이 유지되어야 한다. 이는 VPN에서 가장 중요시 되는 요구사항 중의 하나이다.

- QoS 지원: QoS 보장은 주요 VPN 요구사항 중의 하나이다. 특히 VPN 고객의 QoS는 일반 IP 고객들의 QoS 상태에 영향을 받아서는 안 된다.

IV. 공중망에서의 IPOA 해법

1. IPOA 해법에 대한 ITU-T 표준화 동향

본 고의 서론에서 기술한 것처럼, ATM 망에서 IP 서비스를 제공하기 위한 기술로써 C-IPOA, MPOA 및 MPLS 등이 제안되어 왔다. 지난 '99년 9월 ITU-T SG13 IP Expert 회의에서는(관련권고안 I.ipatm), 공중망에서의 IPOA 해법으로 MPLS 기술을 표준으로 결정하였다. 특히, 이러한 결정은 IP diffserv 및 VPN 서비스에 대하여 MPLS 기술이 더 효과적이라는 분석에 근거한다. IP intserv의 경우에는 C-IPOA가 MPLS와 유사한 장점을 가지는 것으로 판단되나, 공중망에서 단일 해법을 권고하는 것이 바람직하다는 관점에서 ITU-T는 MPLS를 단일 IPOA 해법으로 결정하였다.

MPLS를 단일 해법으로 결정한 구체적인 근거로는 다음 사항을 들 수 있다.

- 망 규모(network size) 관점: MPOA는 소규모 망에는 매우 적합하지만 대규모 망에 적용될 때 소위 N-square의 확장성 문제를 갖는다. 따라서 대규모 공중망에서는 MPOA에 비해 확장성 및 유연성이 좋은 MPLS가 선호된다.

- 링크계층 관점: MPLS는 다양한 링크계층에서 운용되도록 설계되었기 때문에, 다양한 링크계층의 망과 연동을 필요로 하는 공중 ATM망에 적합하다.

- IPOA 망에서의 ATM 제어 관점: MPLS는 소위 ship in the night 방식을 사용하여, 하나의 ATM 장비에서 MPLS 신호방식과 ATM 신호방식[4]이 모두 지원되도록 설계된다.

- IP 트래픽 관리 관점: ATM은 트래픽 관리 측면에서 매우 효율적인 기술이며, MPLS 신호방식은 ATM 신호방식과 유사하게 설계 되었기 때문에, 망 사업자 관점에서 MPLS는 효과적인 트래픽 관리 기능을 제공한다.

- 기존 투자 설비 관점: MPLS는 기존 ATM망에서도 ship in the night 방식으로 보급될 수 있으며, 다른 링크계층 망에서도 유연하게 배치될 수 있기 때문에, 기존 투자 설비를 그대로 활용할 수 있다.

- VPN 지원 관점: MPLS의 주요 장점중의 하나는 QoS 라우팅을 가능하게 하며 연결지향 서비스를 제공한다는 점이다. 또한 동적 터널링(tunneling) 기능도 제공하여 VPN 논리적 망을 유연하게 구성할 수 있다.

- IP QoS 지원 관점: MPLS는 IP diffserv를 목표로 개발된 기술이다. 기본 철학 및 망 운용 방식이 매우 비슷하다. 공중망에서 diffserv 방식이 IP QoS 제공을 위해 널리 쓰일 것으로 전망됨에 따라 MPLS 방식이 선호된다. IP intserv의 경우에 있어서도 C-IPOA 방식과 유사한 장점을 갖는 것으로 분석된다.

2. 공중 ATM 망에서의 MPLS 망 구조

(그림 9)는 공중 ATM 망에서의 MPLS구현에 대한 일반적인 네트워크 모델을 보여준다.

ATM 기반 MPLS 망은 LER과 LSR로 구성된다. LER은 망의 진입(ingress) 및 출구(egress)에 위치하여 IP 트래픽 특성을 ATM 기반 MPLS서비스 특성으로 매핑시켜 주는 역할을 한다. 매핑된 IP 트래픽 전송을 위해 LDP 신호방식이 사용되며, IP 패킷에 대한 전송경로가 얻어진다. 이러한 경로를 LSP라 한다. LSP 상에 위치한 각 LSR들은 QoS를 위한 자원 예약을 하고, 필요한 패킷 처리 정보를 공유하게 된다.

3. 공중 ATM 기반 MPLS 망에서의 제어 프로토콜

공중 ATM 망에서 MPLS 구현을 위해서는 IP 패킷에 대한 제어 프로토콜이 필요하다. 이미 IETF MPLS 표준화 그룹에서는 LDP[19], CR-LDP(Constraint based Route LDP)[20] 및 RSVP 확장[21] 등의 다양한 제어 프로토콜 해법들을 제안하여 왔다. 공중 ATM 기반 MPLS 망에서는 다양한 망끼리의 연동 및 표준화 관점에서 단일 제어 프로토콜 대안을 선택하는 것이 바람직하다.

ITU-T는 공중 ATM 기반 MPLS 망 구현을 위해 다음과 같은 MPLS레이블(label) 분배(distribution) 제어 방식을 권고하고 있다.

- 레이블 전달(advertisement) 방식: ATM 기반 MPLS 망에서는 ATM VCI/VPI가 MPLS 레이블로 사용된다. 현재까지 두 가지의 레이블 전달 방식이 제안되어 왔다.

① 별도의 레이블 분배 방식(예: LDP)

② 기존 프로토콜을 이용하는 piggybacking 방식(예: RSVP, BGP 등)

두 가지 모두 사용될 수 있지만, ITU-T에서는 ①번 방식을 권고한다. 사실상 이 해법은 IETF에서도 어느 정도 합의된 의견을 보이고 있다.

- 레이블 할당(allocation) 방식: LSR 간에는 다음과 같은 방식으로 레이블이 할당될 수 있다.

① Unsolicited downstream 방식

② Downstream on demand 방식

두 가지 방식 중에 ②번 방식이 선호된다. ①번 방식에서는 레이블 요청 메시지 없이도 레이블이 할당 되기 때문에 불필요한 VCI/VPI들이 낭비될 수 있기 때문이다. 한편 ②번 방식에서는 레이블 요청이 있을 때에만 레이블 할당이 이루어진다. 또한 ②번 방식은 사실상 기존 ATM 신호방식과 유사하여, 둘 사이의 연동 측면에서도 장점을 갖는다.

- LSP 제어 방식: MPLS LSP 제어를 위해 다음 두 가지 방식이 제안되어 왔다.

① 순차적 제어 방식

② 독립적 제어 방식

독립적 제어 방식은 각 LSR들이 FEC(Forwarding Equivalence Class) 혹은 LSP에 대해 독립적으로 레이블을 할당 하기 때문에, 같은 LSP에 대한 레이블 할당 과정에서 각 LSR들이 일치되지 않는 결정을 할 수 있다. 순차적 방식은 이러한 문제점이 없으며 특히 VCI/VPI 자원을 사업자의 목적에 맞게 보다 효율적으로 관리할 수 있다.

- 트래픽 관리를 위한 LDP 신호방식: MPLS망에서 IP 트래픽 관리 문제는 QoS 라우팅 및 망자원 관리 측면에서 매우 중요한 이슈이다. 그동안 두 가지의 방식이 제안되어 왔다.

① CR-LDP

② RSVP-TE(Traffic Engineering) 확장

이 문제는 그동안 IETF에서도 많은 정치적 논쟁이 있었다. Cisco System사에서는 RSVP-TE 방식을 제안하여 왔고, Nortel Networks 및 Lucent사를 중심으로 한 여러 장비제조업체들은 CR-LDP를 제안하여 왔다. ITU-T에서는 결국 CR-LDP 방식을 표준으로 채택하였다. 그 이유는 다음과 같다.

* LDP와 CR-LDP는 같은 종류의 프로토콜이다.

* CR-LDP는 TCP를 기반으로 작동하고 RSVP-TE는 UDP를 기반으로 운용되기 때문에 프로토콜 신뢰성 측면에서 CR-LDP가 선호된다.

* 확장성 측면에서도 CR-LDP는 diffserv 개념과 유사하고, RSVP는 intserv 개념과 유사하여 CR-LDP가 대규모 망에서 확장성이 우수하다.

* CR-LDP는 ATM 신호방식과 유사하여 둘 사이의 연동측면에서 선호된다. 특히 CR-LDP는 ATM처럼 송신자 기반으로 운용되는데 비하여, RSVP는 수신자 기반으로 운용된다.

일부 전문가들은 이 이슈를 통신사업자의 구현 문제로 분류하여, 두 가지 모두 표준으로 권고하여 사업자의 선택에 맡겨야 한다고 주장한다. 특히 기존의 인터넷 환경은 RSVP 철학과 부합되는 측면이 많고, CR-LDP는 Nortel Networks사 등 기존의 전기통신사업자 기반의 제조업체들이 개발하여 ATM 통신 철학과 유사한 점이 많다. 그러나 한가지 목적을 위해서는 한가지 프로토콜을 선택한다는 ITU-T의 방침에 따라 '99년 9월 ITU-T 회의에서 CR-LDP가 표준으로 결정되었고, 2000년 3월 일본 교토 회의에서 최종 권고안 승인될(frozen) 절차가 남아 있다.

V. 결 론

지금까지 공중 ATM 통신망에서의 IP 서비스 전송 기술에 대해 ITU-T 표준화 동향을 중심으로 살펴보았다. 인터넷 서비스의 성장으로 인해 차세대 인터넷에서는 초고속의 QoS 보장 IP 전송기술이 절실히 요구된다. 본 고에서 살펴본 것처럼, 현재 이러한 기술 관련 표준화 작업이 본격적으로 진행되고 있으며, 조만 간에 상당 부분의 표준들이 결정될 전망이다.

현재까지의 표준화 작업을 토대로 향후에 다루어질 이슈에 대해 정리하면 다음과 같다:

- 공중 ATM 망에서의 MPLS 배치 전략: MPLS는 최근 기술이고 아직 공중 ATM 망에 널리 보급되지 않았다. 따라서 IP 서비스 제공을 위해 어떠한 방식으로 MPLS를 공중 ATM 망에 보급할 것인가에 대한 전략 혹은 정책적 이슈가 해결되어야 한다. 예를 들어 ATM 망 관리 기능이 전혀 배제된 MPLS 망으로 진화될 수도 있으나, 가능한 기존 ATM의 장점을 살려서 두 방식을 효과적으로 혼합하는 망으로 진화될 수도 있다. 또한 하나의 ATM 장비에서 ATM 및 MPLS 서비스가 모두 제공되는 경우, VCI/VPI 레이블 할당에 관한 문제도 해결되어야 한다[23, 24].

- MPLS LDP/CR-LDP와 기존 ATM 신호방식과의 연동 문제: MPLS를 지원하지 않는 공중 ATM 망과의 연동 문제가 논의되어야 한다[22].

- MPLS망에서의 QoS 서비스 제공: MPLS 망에서 IP diffserv 및 intserv 등의 QoS 서비스를 제공하기 위한 구체적인 세부 기술들에 대한 검토가 필요하다. 또한 다양한 QoS 서비스간의 연동 및 호환 문제도 공중망에서 다루어져야 한다.

- MPLS망에서의 멀티캐스트: ATM에서의 멀티캐스트 서비스 제공 기술은 아직 해결되고 있지 않은 것처럼 MPLS망에서의 멀티캐스트 지원 기술이 다루어져야 한다.

최근 차세대 인터넷 국제 표준화 동향을 살펴보면, 기술개발과 관련 표준화 작업이 동시에 추진되는 것을 볼 수 있다. 이는 관련 기술의 지적재산권 행사와 시장점유 측면에서 표준화의 역할이 매우 큼을 반증하고 있다. 따라서 우리의 자세도, 기존에 개발 완료된 국제표준 기술을 습득, 모방하는 과거의 소극적 자세에서 벗어나, 수익성 높은 차세대 인터넷 기술을 중점 개발하여 ITU-T 혹은 IETF 등의 국제표준화 기구에 개발 표준을 반영하는 적극적인 자세가 필요하다.

<참 고 문 헌>

  1. ITU-T, Transport of IP over ATM in Public Networks, Draft Recommendation I.ipatm (determined), 1999.
  2. ITU-T, B-ISDN ATM layer cell transfer performance, Recommendation I.356, 1996.
  3. ITU-T, Support of the Broadband Connectionless Data Bearer Service by the B-ISDN, Recommendation I.364, 1995.
  4. ITU-T, Digital subscriber Signaling System No. 2 ? UNI layer 3 specification for basic call/connection control, Recommendation Q.2931, 1995.
  5. ITU-T, Traffic control and congestion control in B-ISDN, Recommendation I.371, 1996.
  6. ATM Forum, Multiprotocol over ATM Version 1, AF-MPOA-0087.000, July 1997.
  7. IETF, Multiprotocol Encapsulation over ATM Adaptation Layer 5, RFC 1483, July 1993.
  8. IETF, Resource Reservation Protocol(RSVP) ? Version 1 Functional Specification, RFC 2205, September 1997.
  9. IETF, Specification of the Controlled-Load network element Service, RFC 2211, September 1997.
  10. IETF, Specification of Guaranteed quality of Service, RFC 2212, September 1997.
  11. IETF, Classical IP and ARP Over ATM, Category, RFC 2225, April 1998.
  12. IETF, Next Hop Resolution Protocol, RFC2332, April 1998.
  13. IETF, An Architecture for Differentiated Services, RFC 2475, December 1998.
  14. IETF, BGP/MPLS VPN, RFC 2547, March 1999.
  15. IETF, Assured Forwarding PHB Group, RFC 2597, June 1999.
  16. IETF, An Expedited Forwarding PHB, RFC 2598, June 1999.
  17. IETF, Multiprotocol Label Switching Architecture, draft-ietf-mpls-arch-05.txt, April 1999.
  18. IETF, A Framework for Multiprotocol Label Switching, draft-ietf-mpls-framework-04.txt, July 1999.
  19. IETF, LDP Specification, draft-ietf-mpls-ldp-05.txt, June 1999.
  20. IETF, Constraint-Based LSP Setup using LDP, draft-ietf-mpls-ldp-02.txt, August 1999.
  21. IETF, Extensions to RSVP for LSP Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-02.txt, March 1999.
  22. IETF, The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol, draft-ietf-mpls-git-uus-02.txt, March 1999.
  23. IETF, VCID Notification over ATM link, draft-ietf-mpls-vcid-atm-03.txt, April 1999.
  24. IETF, MPLS using LDP and ATM VC Switching, draft-ietf-mpls-atm-02.txt, April 1999.