Introducing Typical Label Distribution in Frame-Mode MPLS

MPLS Unicast IP Routing Architecture

• MPLS 에서는 label 에 의하여, 포워딩이 결정 된다.

• 다이렉트로 연결된 장비가 그들의 네이버에게 label 정보를 전달 해야 한다 .

•이때 아래 두가지 방법이 처음 고려 되었다.

     1)존재하는 라우팅 프로토콜을 이용하는 방법

     2)레이블을 전달하기 위한 프로토콜 설계

=> 새로운 라우팅 프로토콜을 만드는 것이 사용 되는데, 이때 label 담아 수정 하기에 ip라우팅 프로토콜이 너무 많기 때문에 새로운 라우팅 프로토콜이 개발 되었다.

단, 존재하는 라우팅 프로토콜을 이용하는 방법은 VPN시 사용 되게 된다.

- 아래 LSR에서 패킷이 포워딩 되는 과정을 나타낸것이다.

(외부에서 label이 있는 패킷이면 LFIB, 아니면 FIB를 이요)

- 처음에 CP 부분에서 ospf 업데이트 경로가 오게 되어 RIB 로 올라오게 된다.그리고 RIB 는 FIB로 전달 되어 FIB에 의하여 

패킷이 들어 오면 포워딩 된다.

- 만약 MPLS가 동작 하게 된다면 해당 네트워크가 local에서 25, next hop 이 23으로 LIB에서 붙게 되며 해당 label정보는 FIB,LFIB에도 돌으로게 되어,

아이피나, LABEL이 들어 와도 LABEL 을 붙여 mpls 망으로 들어 올 수 있게 된다.

Label-Switched Path

• An LSP is a sequence of LSRs that forwards labeled packets of a certain forwarding equivalence class.

=>FEC에 따라서 LSR 은 label 을 포워딩 하기 위해서 LSP를 생성 한다.

– MPLS unicast IP forwarding builds LSPs based on the output of IP routing protocols.

=> MPPLS IP 유니캐스트 전송은 일반적인 아이피 라우팅 전송에 기초하여 만들어 진다.

– LDP advertises labels only for individual segments in the LSP.

=>LSP는  LDP에 의하여  label을 광고한다.

• LSPs are unidirectional.

=>LSP는 단방향으로 설계되었다. => 서로 LSP는 return 되는 트래픽에 대하여 LSP가 다를 수 있기 때문에 단방향으로 설계 되었다고 함.

- 아래 그림처럼 path 를 찾기 위해 라우팅 업데이트를 진행 한다.

- 라우팅 업데이트가 종료 되면 아래 그림처럼 lsp path를 보고 경로를 찾아 갈 수 있다.

Propagating Labels Using PHP

- 더블 lookup -> 두번 조회 하는 것은 최적 패킷 forwarding 방법이 아니다.

- label 은 한 홉 이전 제거 할 수 있다.

- 일반적으로 mpls 에서 ip망으로 나가는 edge lsr에서는 LFIB 에서 NH가 없기 떄문에 label 을 지우고  FIB를 보고 아이피를 lookup 한뒤 포워딩 한다.

그렇게 될 경우 , 불필요하게 2번 lookup 된다.

- 이때 edge 라우터에서 해당 next hop이 connected된 외부 아이피 망이면  label 번호를 3번으로 지정해서 

인접  lsr 로 보내 준다 . 이때 lsr은 3번 label 을 받아서 pop(Penultimate Hop Popping)이라는 것을 인식, outer label 만 제거 해서 보내게 되고 

edge lsr 은 LFIB를 참조 하지 않고 바로 FIB를 참조 하여, connected 되어 있는 네트워크로 보낸다.

이때 1번 lookup 하기 때문에 좀더 효율적이다.

=> 별도의 설정 할 필요 없이 connected 되어 있는 네트워크면 인접 장비에 pop으로 label 을 지정 한다.

- pop을 받은 장비는 implicit null 이라고도 확인이 되는데, 기본적으로 mpls 는 implicit null로 설정 되어 있다.

implicit null 인 경우는 만약 , qos 설정을 위해 exp 필드가 사용되는 경우 exp필드도 없이 모든 해더가 없어지나, emplicit null 이 설정된경우

해더에 label 은 null 로 설정 되고 exp 필드가 사용되어 보내 진다.

*만약 connected 가 아니고 next hop 이 있는 경우 untag / no label 이라고 action 이 되면 ,label 을 모두 제거 되고 next-hop으로 아이피체계로 보낸다.

(이때도 FIB를 lookup하지 않고 next-hop으로  1번만 lookup 해서 forwarding 하게 된다.)

• Penultimate hop popping 는 mpls의 퍼포먼스를 최적화 한다.

• cell모드는 사용 할 수 없다,

• pop은 leabel 3으로 전달 해서 outer label 만 제거 해서 보낸다.

Impact of IP Aggregation on LSPs

아래그림에서 E는 자신에게 connected 되었기 때문에 10.1.1.0/24 가 pop으로 label 되어 정보 전달된다.

이때 C에서10.1.0.0/16으로  aggregation 되면 C의 RIB 에는는 10.1.1.0/24 와 10.1.1.0/16 의 null 라우팅 두개가 존재 한다.

그러면 10.1.1.0/24 를 B에서 모를 경우 ,B에 label 에 null 라우팅 은 c에서 connected 되어 있는 것으로 인식 되어 10.1.0.0 에 대하여 pop으로 보내게 되어 

B에서 C로 보낼 때 pop label 을 보고 outer label 을 제거 한뒤 아이피로 C로 전달 된다.

이럴 경우 2번 lookup 되는는 통신 자체에는 이상이 없다(단,MPLS VPN과 TE와 같이 2개 이상의 label이 있을 경우 

C에서는 해당 label 을 unknwon label로 인식 하고 cisco 장비는 drop되는 문제점이 생긴다.)

• IP aggregation 는 lsp를 쪼개어 버린다.

•아래 환경에서는 aggregation을 진행 하면 안된다.

– MPLS VPNs

– MPLS TEs

– MPLS-enabled ATM network

– Transit BGP where core routers are not running BGP

Label allocation and distribution in a frame-mode  MPLS network follows these steps:

•  라우팅 프로토콜은 아이피 라우팅 테이블을 만든다.

•  각 LSR는 라우팅 테이블에 있는 모든 도착지에 대하여 label을 추가 한다.

•  LSR 들은 레이블을 광고 한다.

• 모든 LSR은 수신된 label을 기반으로 LIB,LFIB및 FIB데이터를 작성 한다.

Label Distribution and Advertisement

- cisco 장비는igp 프로토콜과 틀리게, label binding 은 모두에게 upstream,downstream 모두  전달한다.(best 쪽에도 전달)

(패킷이 올라가는 경우를 upstream,내려 가는 경우 downstream 이라고 함)

=>모든 label 을 저장 하기 때문에 대체 경로로 변경시 컨버전스 시간을 단축 할 수 있다.

- 모든 LSR은 LIB에 수신된 label을 모두 저장 하며, 자신의 다음 홉에서 labelw정보를 LFIB에 올리게 된다.

Loop Detection

• LDP 경로를 결정할때 loop를 방지 하기 위해서 IGP를 이용 한다.

•만약 ip에서 mpls로 ttl복사 되지 않는다면 ttl 이 255 로 다시 설정 된다.

=> TTL은 label해더에 ip해더 에  복사 혹은 반대로 되면서 loop를 방지 할 수 있다..(TTL propagation)

• cisco 는 기본적으로 해당 기능 이 사용 되도록 설정 해야 한다.

• On ingress: 들어 오면 ttl은 ip해더에 label해더로 복사 한다.

• On egress: 나갈때는 mpls 해더에 ttl 을 ip 해더로 복사 한다.

- 아래 그림 처럼 ttl이 감소 하면서 0 이 되면 ip와 동일 하게 패킷이  drop된다.

Disabling TTL Propagation

• TTL propagation은 disabled 시켜 복사를 하지 않도록 할 수 있다.

•  disabling ttl 은  mpls 도메인에서 코어 라우터를 숨긴다.

•  traceroute 시 코어 라우터를 표시 하지 않는다.

- 아래 그림에서 d에서 drop되지만, 실제로는 c에서 label 이 떄어진 패킷이 오기 때문에 해당 c에서 drop된다.

(MPLS domain 에서 deg lsr 은 ttl propagation 을 하면 보인다.)

Impact of Disabling TTL Propagation

•TTL Propagation사용하면 core router 가 traceroute 시 보이지 않는다.

•설정시 모든 라우터에 TTL Propagation 설정이 되어 있어야 하며, 일부만 TTL Propagation 설정시 문제가 발생 할 수도 있다.

Allocating Per-Platform Labels

• 하나의 라우터는 하나의 인터페이스만을 포함 하지 않는다.

• per-platfrom 방식은 per-interface 방식과 다르게 모든 인터페이스에서 동일한 label을 사용 할 수 있다,

• LSR은 병렬로 연결 되어 있더라도 1개의 tcp세션으로 1개의 label 로 전달된다.(아래 A,B사이 와 같은경우)

Per-Platform Label Allocation: Benefits and  Drawbacks of Per-Platform Label Allocation

- 아래 그림 처럼 만약 B에서 필터링을 통해 라우팅정보를 전달 하지 않더라도 label은 전달 하는 보안상 문제가 발생 할 수 있다.

----------------------------------------------------------------------------------------------------------------------

*MPLS TRACEROUTE

기본적으로 traceroute 의 진돝적인 방식은

출발지에서 도착지로 UDP패킷을 보내는데, 이때 30000번이상의 포트로 ttl 1로 설정하여 보낸다.

수신한 라우터는 이 datagram을 forward 하는 대신(목적지 호스트경우는 이 datagram을 application으로 전달한다),

 datagram를 폐기시키고는 송신 호스트에 ICMP “time exceeded” message를 되돌려 보낸다.)

이 ICMP message를 포함하고 있는 IP datagram엔 해당 라우터의 IP 주소가 포함되어 있는데, Traceroute는 이를 이용하여 route를 추적한다

목적지 호스트의 UDP모듈에 이 datagram이 도착할 때  “port unreacheable error를 발생케 하며,  이로써 송신지 호스트는 목적지에 도달했음을 알게 된다.

이떄, 이방식에서 MPLS를 전통적인 방식에서 사용 할 경우 core망에서 udp datagram을 보고 icmp time exceeced 패킷을 RIB를 보고 못 보내기 때문에

TRACEroute 가 정상 적으로 되지 않느다.

그래서 MPLS 에서는 traceroute 는 lsp 를 보고 nexthop 까지 전달 후 edge router 에서 정보를 알고 있기 때문에 core가  icmp 를 보내지 않고

출발지 정보를 알고 있는 EDGE LSR이 대신 ICMP로 응답 해준다.