출처
세그먼트 라우팅이 뭘까?
•
•
네트워크의 전송 라우터 및 노드에서 네트워크 상태 정보를 제거하고 경로 상태 정보를 수신 노드의 패킷 헤더에 배치합니다.
•
정보가 전송 노드에서 패킷으로 이동하기 때문에 세그먼트 라우팅은 네트워크 변화에 대한 응답성이 높아 다른 트래픽 엔지니어링 솔루션보다 민첩하고 유연합니다.
•
SR은 트래픽 엔지니어링 기능을 통해 애플리케이션 QoS(Quality of Service)를 제공하며, 네트워크를 통과할 때 최종 사용자와 애플리케이션에 네트워크 서비스를 매핑할 수 있도록 해줍니다.
세그먼트 라우팅 개요
•
세그먼트 라우팅을 이해하려면 먼저 세그먼트 라우팅의 기본 구성 요소를 이해해야 합니다.
SR 도메인: SR 프로토콜에 관여하는 노드 집합입니다. SR 도메인 내에서 노드는 수신/전송/송신 절차를 실행할 수 있습니다.
SR 경로: SR 수신 노드와 SR 송신 노드를 연결하는 세그먼트들을 순서대로 나열한 것입니다. 일반적으로 수신에서 송신까지 최소 비용의 경로를 따릅니다.
SR 세그먼트: 패킷을 네트워크 토폴로지의 어떤 섹션으로 통과시키는 전달 명령입니다. SR은 많은 SR 세그먼트 유형을 정의하며, 가장 자주 사용되는 두 가지는 인접(adjacency) 세그먼트와 접두사(prefix) 세그먼트입니다. 인접 세그먼트는 엄격한 기준으로 전달된 단일 홉 터널입니다. 이는 패킷이 링크 비용에 관계없이 두 노드 사이의 IGP(Internal Gateway Protocol) 인접과 연결된 지정된 링크를 통과하도록 합니다. 접두사 세그먼트는 동일한 비용의 다중 홉 인식 최단 경로 링크를 사용하여 접두사에 도달하는 다중 홉 터널입니다.
세그먼트 라우팅은 데이터센터, 코어, 에지, 액세스 네트워크와 같은 개별 도메인에 구축됩니다.
SRv6+ 세그먼트 라우팅 헤더
•
많은 사람들이 세그먼트 라우팅에 대해 고심하고 있던 중에 갑자기 SRv6가 등장했다. 그리고 SRv6+가 나왔다.
•
그럼 SRv6+이 왜 필요하고, 왜 중요할까?
•
SRv6가 무엇인지 간략하게 살펴보자. 사실상 세그먼트 라우팅에는 다양한 유형의 세그먼트 ID가 있습니다. 이러한 유형은 https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-02에서 확인할 수 있습니다. 모든 SID를 자세히 설명하지는 않겠지만, 오늘날 대부분의 SR은 유형 1 SID(기본적으로 MPLS 레이블)를 사용하며, 일부 유형 3 SID는 컬러리스(colorless) SR의 첫 번째 홉을 위한 TE 경로 형성에 사용됩니다. 더 많은 SR 기반 제품이 개발됨에 따라 다른 SID 유형이 나타나기 시작했지만, 이것이 가장 일반적인 케이스입니다.
•
그러나 SRv6은 레이블 위치에 확장된 헤더의 IPv6 주소를 사용합니다. 이러한 헤더는 라우팅 확장 헤더에 배치되어 스택됩니다. SRH는 64비트 “헤더”로 구성되어 v6 SID로 스택됩니다. 즉, 최소 192비트의 추가 데이터가 SRv6 패킷에 포함되어 있습니다. 그에 비해 MPLS 헤더는 32비트 길이입니다(20 비트 레이블 + 3 Traffic Class + 1 Bottom of Stack + 8 TTL) 이것은 오버헤드에 대한 상당한 부담을 가져오며 레이블 4개 깊이로 스택하는 경우는 상상할 수 없을 정도입니다. 둘째, 사실상 SRv6는 IPv6 주소만 사용하는 것이 아니라 IPv6 주소도 사용하는 것입니다. 그러므로 V6 주소가 오버로드됩니다. 실제 상황에서 이러한 오버로드의 악영향을 평가하는 것은 현실적으로 어렵지만, 저는 IPv6 주소를 IPv6 주소로 간주하면서 상황이 더욱 빠르게 악화될 수 있다고 생각합니다.
•
이제 앞서 언급했듯이 SRv6+에 대해 이야기 해 봅시다. SRv6+는 사실상 4개의 초안이 결합된 개념으로 여기에서 찾아볼 수 있습니다.
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-03https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-05https://tools.ietf.org/html/draft-bonica-6man-oam-03
•
이러한 초안 중 첫 번째 안에서는 표준 v6 세그먼트 라우팅 헤더를 CRH(Compressed Routing Header)로 대체합니다. CRH는 8, 16 또는 32비트 길이의 SID 목록을 사용하고 이러한 SID는 다른 IPv6 주소에 매핑됩니다. 향후 게시글에서 이것이 정확히 어떻게 작동하는지 자세히 알아보겠습니다. 하지만 기존 SRH가 가하는 엄청난 오버헤드를 제거함으로써 실제적으로 SRv6를 기능하게 한다고 할 수 있습니다. CRH 없이는 어떤 오퍼레이터도 오버헤드를 가하는 SRv6를 사용할 수 없을 것입니다.
•
두 번째 초안에서는 소스 노드가 IPv6 주소에서 중간 노드로 전송하는 명령을 분리합니다. 기본적으로 일반적인 SRv6의 경우 https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05 에서 확인할 수 있습니다. 섹션 4에서 SID와 연결할 수 있는 방대한 기능 목록이 정의되어 있습니다. 주의하실 점은 현재 맥락에서 V6 SID는 V6 주소이므로 주소 오버로드가 발생한다는 것입니다. 하지만 세그먼트 측면의 옵션 초안에서는 주소 공간의 오버로드 없이 명령과 기타 정보를 전송하는 선택적 헤더가 있습니다.
•
세 번째 초안은 사실상 MPLS 레이블을 처리할 수 없지만 VPNv6를 필요로 하는 디바이스에 대해 VPN 컨텍스트 정보를 전달하는 비MPLS 레이블 방법을 설명합니다. (여기에 대해서는 향후 게시물에서 좀더 알아보도록 하겠습니다.)
•
네 번째 초안에서는 RFC는 내장된 OAM 명령을 허용합니다. 기본적으로 소스 노드가 특정 작업을 수행하기 위해 더 복잡한 경로에 있는 노드에 지시를 내릴 수 있습니다. 이러한 작업에는 패킷 로깅, 패킷 카운트, 소스로 ICMPv6 OAM 패킷 재전송, 수집기로 특정 텔레메트리 데이터 재전송이 포함될 수 있습니다. SR의 스테이트리스(stateless) 특성을 고려하면 이러한 명령을 내장할 수 있는 기능을 흥미롭고 유용하게 활용할 수 있을 것입니다. 예를 들어, 패킷의 도착 시간과 패킷 자체를 포함하는 텔레메트리 데이터를 전송하도록 경로상의 각 노드에 지시할 수 있다면, 각 노드에서 수신한 데이터를 상호 연계하여 경로에 있는 노드 간 실시간 지연 측정 정보를 제공하도록 할 수 있을 것입니다.
•
우리가 SRv6+를 주목하는 이유는 무엇일까요? SRv6가 부과하는 오버헤드를 허용할 수 없기 때문에 IPv6 주소의 오버로드는 부적절할 뿐 아니라 위험합니다. OAM RFC가 제공하는 OAM 옵션은 컨트롤러, 머신 러닝 및 기타 기술이 네트워크에 침투하고 있는 세상에서 획기적인 가능성을 보여줍니다.
•
이제 이 기술이 어떻게 발전할지 지켜보는 일은 흥미로울 것입니다. 초안은 수정되고 구체화될 것이지만, MPLS 글로벌 포럼 등에서 제가 관찰한 바에 따르면 SRv6의 시대가 도래하고 있다는 것입니다. 그리고 마지막 남은 질문은 그것이 어떠한 형태를 갖출 것인가 하는 점입니다. 저는 비용적인 측면 때문에서라도 상상할 수 없는 오버헤드와 주소 공간의 오버로드를 가져오지 않는 기술을 선호합니다. 또한 오버헤드를 해결하기 위해 라우터 인터페이스 업그레이드가 필요 없는 솔루션을 원할 것입니다.