Juniper의 MPLS Traffic Engineering Architecture
2000년 02월 16일

손장우
son@netmanias.com
02-556-9273 www.netmanias.com

이글에서는 MPLS 트래픽 엔지니어링 기술에 관해, Juniper의 router-based MPLS traffic engineering architecture를 중심으로 기술하였습니다. (원문: Traffic Engineering for the New Public Network, Juniper Networks white paper)  이 글에서는 MPLS 트래픽 엔지니어링의 네 가지 핵심 요소(패킷-포워딩, 라우팅 및 링크 속성 정보 분배, 경로 선택, 신호 방식)를 설명하고 있습니다.

MPLS 네트워크에서 Explicit-routed LSP를 설정하는 방법은 여러 가지가 있을 수 있는 데, 네트워크 운영자가 수동으로 설정하는 방법과 IGP extention, CBR (또는 QOSR, 여기서는 CSPF), Signaling 절차를 이용해 자동으로 설정하는 방법을 들 수 있으며 여기서는 후자의 경우를 기술하였습니다.   Juniper의 MPLS traffic engineering architecture는 다음과 같은 4 가지 기능 요소(functional component)로 이루어진다.  1. Packet forwarding component 2. Information distribution component  3. Path selection component 4. Signaling component  

그림 0. Juniper의 router-based MPLS traffic engineering architecture
각 기능 요소는 독립적인 모듈로 구현되며, Juniper의 트래픽 엔지니어링 아키텍처는 4 기능 요소로 이루어진다. 이러한 modularity로 인해 개개의 기능 요소에 더 나은 솔루션이 생기게 되면 그 기능 요소만 변경하면 되므로 유연성(flexibility) 측면에서 바람직한 구조이다.      ▣ Packet forwarding component   Juniper 트래픽 엔지니어링 아키텍처에서 Packet forwarding component는 MPLS이다. MPLS는 IP 패킷의 플로우(flow)를 MPLS 네트워크상에 미리 정해진 경로를 따라 전달하는 역할을 담당한다.   이 경로를 LSP (label-switched path)라고 부르며 ATM에서 VCC과 유사하다. LSP는 MPLS 네트워크의 ingress LSR(혹은 LER(Label Edge Router), Head-end LSR이라고도 불리운다.)과 egress LSR(역시 LER 또는 Tail-end LSR이라고도 불린운다.)간에 설정되며 하나 혹은 여러 개의 label-switched hop의 연결로 이루어진다. 여기서, LSR(label-switched router)이란 MPLS를 지원하는 라우터를 의미한다.   ingress LSR에 IP 패킷이 도착하면, LSR은 MPLS 헤더를 부착하고 해당 LSP상의 next LSR로 포워딩한다. 이 패킷을 labeled packet이라고 불리우며, 이 labeled packet은 LSP상의 LSRs에서 label값을 참조하여 포워딩되며, 최종적으로 egress LSR에 도착한다. 여기서, MPLS 헤더는 제거되며 IP 패킷이 추출된다. 이 IP 패킷은 그 패킷의 destination IP address를 참조하여 다음 라우터로 포워딩된다.  여기서, 중요한 점은 LSP의 물리적인 경로가, IGP의 최단 경로(shortest path)를 꼭 따르는 것은 아니라는 점이다(그림 1).  

그림 1. MPLS 도메인에서 LSP의 예
각 LSR에서 패킷-포워딩 절차는 ATM과 같은 레이블-스워핑(label-swapping) 개념에 기초한다. 각 MPLS 패킷 (labeled packet)에는 4 바이트 (32비트)의 인캡슐레이션 헤더가 부착되는 데, 이 중 20 비트가 레이블 필드이다.   MPLS 패킷 (labeled packet)이 LSR에 도착하면, LSR은 이 label값을 인덱스로 하여 (IP 패킷의 destination IP address가 아니라) MPLS 포워딩 테이블에서 next hop을 찾아 낸다.   MPLS 포워딩 테이블에는 그림 2에서 보이듯이, {incoming interface, incoming label, corresponding outgoing interface, corresponding outgoing label} 형식의 엔트리로 채워져 있으며, 이 엔트리는 control-driven 방식으로 생성되거나, on-demand로 생성된다. (IP 패킷이 LSR에 도착했을 때, 이 패킷을 전달하기 위해 새로이 LSP를 설정하는 것이 아니라, 실제 데이타 (IP 패킷)이 MPLS 네트워크에 도착하기 전에 미리 설정되어 있다.)

그림 2. MPLS 포워딩 테이블의 예
그림 3에 LSR에서 수행되는 레이블-스워핑 과정의 예가 나타나 있다. LSR의 인터페이스 3번으로 들어온 레이블값이 21인 MPLS 패킷은 그림 2의 포워딩 테이블을 참조하여, 레이블값을 18로 바꾸고(swapping) 인터페이스 4번으로 전달되어 다음 LSR로 포워딩된다.  

그림 3. LSR에서 MPLS 패킷 포워딩 (레이블-스워핑)의 예
Note: 이상에서 알 수 있듯이, MPLS 네트워크에서는 에지(ingress LSR)에서만 IP 헤더 프러세싱(longest prefix matching 알고리즘을 통한 IP address lookup, layer 4 information과 TOS필드 등을 이용한 Multi-field classification)을 하고, 코어 (core)에서는 단순히 레이블값만 보고 스위칭해준다.    MPLS가 출현할 때만 해도 통상적으로 \'LPM를 통한 IP address lookup은 저속(이 때는 프러세서 기반으로 수행했었다.)이고, 고정 길이의 레이블에 대한 Exact matching은 하드웨어적으로 수행되어 매우 고속이다\'라는 논리가 통하였고 따라서, MPLS의 새로운 포워딩 파라다임은 라우터 기반의 IP 네트워크에 비해 고속 포워딩이 가능하며, 이 것이 MPLS의 장점으로 내세워졌었다.    그러나, 현재는 라우터에서 수행되는 longest match 절차를 ASIC 기반으로 수행함으로써, MPLS나 ATM에서의 lookup (exact match) 성능과 차이가 없어졌다. 따라서, MPLS가 IP 패킷을 고속으로 전달한다는 장점은 현재로서는 의미가 퇴색되어 졌다.    그러나, MPLS의 진가는,    

(1) Rouring과 forwarding의 분리로 인해 얻을 수 있는, 라우팅 파라다임의 발전해도 네트워크 포워딩 인프라는 그대로 유지된다는 장점과    
(2) Traffic engineering의 강점, 등에서 여전히 건재하며 현재 MPLS진영에서도 이 두 가지 요소를 MPLS의 진정한 강점으로 주장하고 있다.    

▣ Information distribution compoment
그림 4. Information distribution component  
트래픽 엔지니어링이란 네트워크 자원을 효율적으로 사용하면서 트래픽을 네트워크 전체에 가능한 균등히 분배함으로써 사용자들이 원하는 서비스 품질을 보장해주면서 네트워크 자원의 활용도를 극대화시키는 기술이다.   따라서, 효과적인 트래픽 엔지니어링을 위해서는, 사용자가 요구하는 서비스 품질 정도뿐만 아니라, 현재의 네트워크 부하 상태 정보(예를 들어, 각 링크의 여유 대역폭)와 네트워크 토폴러지 정보(네트워크 구성, 상태, 각 링크 cost 등)가 필요하며, MPLS 네트워크 내의 모든 LSR은 이러한 정보를 알고 있어야 한다. 따라서, 이러한 부하상태정보와 토폴러지 정보를 모든 LSR들에게 분배/전달(distribution)해주는 방법이 정의되어야 한다.   기존의 IGP (IS-IS/OSPF)는 네트워크 토폴러지 정보만 이웃 라우터에게 플러딩(flooding, 모든 인접 라우터에게 브로드캐스팅하는 것)하므로써, IP 네트워크 내의 라우터들에게 이 정보를 분배/전달해준다.   이 IGP에 트래픽 엔지니어링에 필요한 정보, 즉 현재 네트워크 부하 상황(좀 추상적인 말이고 구체적으로는, 각 LSR의 output link에 관한 정보를 말하며 링크의 최대 대역폭, 현재 다른 LSP에 의해 예약된 대역폭, 예약 가능 대역폭 등의 정보를 말한다.  Maximum link bandwidth, Maximum reservable bandwidth, Current bandwidth reservation, Current bandwidth usage, Link coloring)를 link-state와 함께 advertisement하도록 IGP를 확장해주면 된다. 이를 IGP extension이라 부른다.  IS-IS extension은 기존의 IS-IS에 새로운 TLV(Type Length Value)를 추가해주면 되고, OSPF extension은 Opaque LSA로 구현될 수 있다.   link-state IGP는 이 정보들(네트워크 토폴러지 정보 + 링크 속성 정보)을 플러딩하여, ISP의 라우팅 도메인내의 모든 라우터들(즉, MPLS 네트워크 내의 모든 LSRs들)에게 전달/분배한다.   각 LSR은 TED(Traffic Engineering Database)에 네트워크 토폴러지 정보와 네트워크 링크 속성 정보를 저장해 두며, LSP에 대한 explicit route를 계산할 때 이 TED를 이용한다.

▣ Path selection compoment   네트워크 링크 속성과 토폴러지 정보가 IGP에 의해 모든 LSR에 플러딩되고, 이 정보가 각 LSR의 TED(Traffic Engineering Database)에 저장되고 나면, 각 ingress LSR은 이 TED를 이용하여 LSP에 대한 MPLS 네트워크상의 물리적인/실제의 경로(path)를 계산한다.   Ingress LSR은 CSPF (Constrained Shortes Path First) 알고리즘을 TED내의 정보에 적용하여 각 LSP에 대한 물리적인 경로를 결정한다.  CSPF 알고리즘은 특정한 제약 조건을 만족시키는 (ingress LSR과 egress LSR간에) 최단 경로를 찾아내는 알고리즘이다.  CSPF 알고리즘의 입력은 다음과 같다.
(1) Topology link-state information : IGP가 물어다 주고 TED에 저장되어 있다.
(2) Link attributes : IGP extension이 물어다 주고 TED에 저장되어 있다.
(3) 설정하고자 하는 LSP의 속성: LSP의 사용자의 요구사항, 예를 들어, BW requirements, maximum hop count and administrative policy requirements  

그림 5. Path selection component  
CSPF는 새로이 설정할 LSP에 대해 MPLS 네트워크상에 존재하는 경로중에서 LSP의 사용자가 요구하는 요구사항(예를 들어, 예약하고픈 대역폭이 10Mbps)을 만족시키는 경로 중에서 최단 경로를 선택한다.   CSPF 알고리즘의 결과로서 explicit route가 나오는 데, 이 explicit route는 LSP를 설정하려는 ingress LSR에서 목적지 egress LSR까지의 LSP상의 LSRs의 집합(아래 그림 6의 예에서 설정하려고 하는 LSP에 대한 explicit route = {47.14.80.7, 47.14.20.6, 173.95.80.7}) 이다.    

그림 6. CSPF (Constrained Shortes Path First) 알고리즘의 경로 계산의 예  
http://www.cs.tu-bs.de/~sun/visu.html : QoS Routing 과정을 자바를 이용해 애니메이션으로 보여주는 사이트입니다. 한번 가보세요.(강력 추천)     이 explicit route는 signaling component로 전달되고, signaling component는 이 LSP의 라우트상의 LSR에 이 LSP에 대한 forwarding state를 설정한다.      
▣ Signaling component   Signaling component는 apth selection component가 계산한 explicit route상의 LSR들에게, 이 LSP에 대한 연결 설정을 요청하고, forwarding state를 설정하고, 레이블을 분배 (label distribution)하는 기능을 수행하며 두 가지 방식이 제안되어 왔다.  

그림 7. Signaling component  

① LDP를 보완한 CR-LDP(Constraint-based Routing)로 Nortel, Ericsson, Lucent, Ennovate 그리고 GDC가 이 방식을 주장하고 있고,
② RSVP를 수정한 RSVP-TE(Traffic Engineering)으로 Cisco, Juniper, Avici, Argon, Ironbridge 그리고 Torrent가 이 방식을 주장하고 있다.

이 문제는 그동안 IETF에서도 많은 정치적 논쟁이 있었다. 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) 절차가 남아 있다.[공중 ATM망에서의 IP 전송기술 동향, ETRI 주간기술동향 924호, 1999년 12월 1일]   Juniper는 RSVP-TE를 여전히 밀고 있으나, 위에 언급한 이유로 트래픽 엔지니어링 signaling 방식은 CR-LDP로 설명하겠다. RSVP-TE 방식으로 signaling을 수행해도 앞에서 기술한 packet-forwarding component, Information distribution component, path selection component의 기능과 상호 동작은 동일하다.   CR-LDP는 기존의 LDP(label distribution protocol)을 확장한 것으로 Explicit route 정보, 자원예약을 위한 Traffic parameter 정보 그리고 ER-LSP의 장애 복구에 대한 옵션정보 등에 대한 Object를 추가하여 만든 것이다. 아래 그림에 CR-LDP를 이용한 signaling 과정이 나타나 있다.  
    
(a) Label Request message
(b) ER-TLV
(c) ER-Hop TLV
(d) Label Mapping message  그림 8. CR-LDP를 이용한 Explicit routed LSP (ER-LSP)의 설정 절차