많은 사람들이 세그먼트 라우팅에 대해 고심하고 있던 중에 갑자기 SRv6가 등장했고, 그 다음으로 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-03
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-03
https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-05
https://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+를 주목하는 이유는 무엇일까요? SRv6가 부과하는 오버헤드를 허용할 수 없기 때문에 IPv6 주소의 오버로드는 부적절할 뿐 아니라 위험합니다. OAM RFC가 제공하는 OAM 옵션은 컨트롤러, 머신 러닝 및 기타 기술이 네트워크에 침투하고 있는 세상에서 획기적인 가능성을 보여줍니다.
이제 이 기술이 어떻게 발전할지 지켜보는 일은 흥미로울 것입니다. 초안은 수정되고 구체화될 것이지만, MPLS 글로벌 포럼 등에서 제가 관찰한 바에 따르면 SRv6의 시대가 도래하고 있다는 것입니다. 그리고 마지막 남은 질문은 그것이 어떠한 형태를 갖출 것인가 하는 점입니다. 저는 비용적인 측면 때문에서라도 상상할 수 없는 오버헤드와 주소 공간의 오버로드를 가져오지 않는 기술을 선호합니다. 또한 오버헤드를 해결하기 위해 라우터 인터페이스 업그레이드가 필요 없는 솔루션을 원할 것입니다.
