글 : 카심 아르함 주니퍼 네트웍스 수석 아키텍터, 줄리안 루섹 시스템 엔지니어

5G와 오픈 RAN은 새로운 프론트홀 및 백홀 통합구조(X-Haul)가 등장하고, 커버리지를 유지하면서도 사용자에게 원활한 서비스를 제공하기 위해 더 많은 셀 사이트가 필요함에 따라 CSP(Communication Service Providers)에게 새로운 과제를 안겨준다.

새로운 5G 전용 사이트는 C-RAN(Centralized RAN)과 D-RAN(Distributed RAN) 토폴로지가 혼합될 가능성이 높다. C-RAN 사이트는 일반적으로 오늘날의 4G 사이트와 마찬가지로 통신사업자 소유의 대형 사이트다.

반면 D-RAN 사이트는 수만 개에 이를 수 있으며 셀타워 하단 설비함과 같이 소형 임대 공간인 경우가 많다. 소규모 임대 공간을 사용하면 CSP의 비용을 낮추고 비즈니스 유연성을 유지할 수 있지만 반대로 제약이 따를 수 있다.

5G 위한 경험 최우선 네트워킹(Experience-First Networking)

일반적으로 D-RAN 사이트는 전력, 공간, 냉각이 제한적이다. 따라서 모든 컴퓨팅 및 라우팅 기능이 단일 1U 또는 2U 서버에 결합돼야 한다. 또한 연결은 대개 모바일 코어로 재전송하기 위한 전용 회선으로 제한된다.

CSP는 이러한 제약 조건에서 운영하기 위해 D-RAN에서 새로운 접근 방식을 취하고 있으며, 주니퍼 네트웍스는 이러한 환경을 위한 클라우드 네이티브 라우터를 개발했다. 소프트웨어(SW)에 대한 클라우드 네이티브 접근 방식에서 기능 블록은 쿠버네티스(K8s)에 의해 오케스트레이션되는 x86 또는 ARM 플랫폼에 컨테이너로 배포되는 마이크로서비스로 분해된다.

여기에는 AMF 및 SMF와 같은 5G 코어 컨트롤 플레인 기능, CU-CP(Central Unit Control Plane), SMO, 근접 및 비실시간 RIC와 같은 RAN 컨트롤 플레인 기능과 CU-DP(Central Unit Data Plane), DU와 같은 일부 데이터 플레인 기능이 포함된다. K8s 네트워킹은 CNI(Container Network Interface) 플러그인을 통해 구현된다.

그러나 일반적인 CNI의 네트워킹 기능은 초보적인 수준이며 CNI가 제공하는 네트워크 기능이 텔코 네트워크 내에서 중추적인 역할을 해야 하는 경우에는 용도에 적합하지 않다. 이런 경우에 J-CNR(Juniper Networks’ Cloud-Native Router)이 빛을 발한다.

J-CNR은 x86 또는 ARM 기반 호스트가 ISIS 및 BGP와 같은 프로토콜에 참여하고 MPLS/SR 기반 전송 및 멀티테넌시를 제공하는 네트워크 라우팅 시스템의 일급 구성원이 될 수 있도록 하는 컨테이너 라우터다.

즉, 일반 서버 플랫폼이 CE(Customer Edge) 라우터 같은 네트워크의 부속물이 아니라 PE(Provider Edge) 라우터의 역할에 적합할 수 있다. 셀사이트에 구축되는 경우 이 솔루션은 필요한 박스 수를 줄여 설비투자(CapEx)를 줄인다. 또한 그에 상응하는 전력 소비, 공간, 운영 복잡성의 감소를 통해 운영비용(OpEx)를 감소시킨다.

모든 라우터에는 컨트롤 플레인과 포워딩 플레인이 있다. 컨트롤 플레인은 동적 라우팅 프로토콜에 참여하고 네트워크의 다른 라우터와 라우팅 정보를 교환한다. 컨트롤 플레인은 프리픽스, Next-hop, SR/MPLS 레이블 형태로 결과를 포워딩 플레인으로 다운로드한다.

J-CNR을 포함한 주니퍼 라우터에서 컨트롤 플레인은 포워딩 플레인 구현 방식에 관계없이 작동한다. '주니퍼 MX 시리즈' 라우터 같은 기존 하드웨어 라우터에서 포워딩 플레인은 커스텀 ASIC을 기반으로 작동한다.

J-CNR 포워딩 플레인은 다른 구조를 기반으로 실행되지만 주노스(Junos)의 RPD(Routing Protocol Daemon)로 알려진 라우팅 프로토콜 소프트웨어는 두 경우 모두 동일하다.

따라서 J-CNR은 세계 최대 규모의 주요 네트워크들에 구축된 하드웨어 기반 라우터와 동일한 포괄적이고, 강력한 프로토콜 구현의 이점을 갖고 있다. 결과적으로 J-CNR은 소형 소프트웨어 패키지에서 하드웨어 기반 라우터와 동일한 수준의 기능으로 고성능 WAN 네트워킹을 제공한다.

O-RAN 아키텍처의 J-CNR

J-CNR은 D-RAN 또는 RU와 DU가 같은 위치에 있고 상대적으로 낮은 대역폭의 미드홀링크를 통해 CU에 연결되는 싱글 스플릿(Single-Split) 아키텍처용으로 설계됐다.

대부분의 5G/O-RAN D-RAN 아키텍처는 기존의 단일 이전 세대 셀 사이트에서 발전한다. 이 신규 구축은 더 조밀한 커버리지, 더 높은 대역폭, 더 낮은 지연을 달성하기 위해 여러 소규모 사이트로 확장된다.

위의 <그림 1>에서 볼 수 있듯 J-CNR은 주노스 cRPD(Containerized Routing Protocol Daemon) 컨트롤 플레인과 DPDK, 리눅스 커널 또는 스마트-NIC를 통해 구현된 포워딩 플레인을 사용한다. 완전한 통합은 Multus 지원 K8s 환경 내 배포 가능한 K8s CNI 호환 패키지를 제공한다.

DU와 J-CNR은 동일한 1U 크기 x86 또는 ARM 기반 호스트에 공존할 수 있다. 이는 별도의 DU 및 라우터 형태로 된 2박스 솔루션을 제거하므로 전력과 공간이 제한된 사이트에서 특히 유용하다.

<그림 2>는 J-CNR 아키텍처의 세부 사항을 보여준다. 셀 사이트 서버는 K8s 워커 노드이며, 녹색의 기능블록은 주니퍼 네트웍스에서 제공한다. O-DU는 Multus 메타-CNI에 의해 지원되는 다수의 네트워크 인터페이스를 필요로 한다.

이러한 각각의 인터페이스는 여러 네트워크 슬라이스를 지원하기 위해 J-CNR의 다른 레이어3 VPN에 매핑될 수 있다. J-CNR CNI는 K8s 리소스 생성 이벤트에 의해 트리거되는 경우 포드와 J-CNR 포워딩 플레인 사이의 인터페이스를 동적으로 추가하거나 삭제한다.

또한 J-CNR 컨트롤 플레인 cRPD 컨테이너를 각 포드 인터페이스에 대한 호스트 경로와 RD(Route Distinguisher) 및 RT(Route Target) 형태의 레이어 3 VPN 매핑으로 동적으로 업데이트한다.

cRPD는 데이터 경로에 클라우드 네이티브 라우터를 도입해 에지 또는 지역 DC 사이트에서 실행되는 CU에 대한 F1 인터페이스를 지원하는 gRPC 인터페이스를 통해 J-CNR 포워딩 플레인을 적절하게 프로그래밍한다.

위의 <그림 2>에는 단일 O-DU 워크로드가 나와 있지만 실제로는 다수의 O-DU 또는 기타 워크로드를 동일한 클라우드 네이티브 라우터에 연결할 수 있다.

네트워크 운영 혁신J-CNR은 클라우드 네이티브 애플리케이션이므로 K8s 매니페스트 또는 Helm 차트를 사용한 설치를 지원한다.

여기에는 라우팅 프로토콜과 슬라이스를 지원하는 레이어 3 VPN을 포함한 라우터 초기 구성이 포함된다. 네트워크의 나머지 부분과 함께 모든 라우팅 프로토콜 인접성과 함께 몇 초 만에 스핀업된다.

<그림 3>에 나와 있는 것처럼 J-CNR의 수명 동안 네트워크 슬라이스 추가 또는 제거와 같은 지속적인 구성 변경은 주노스 CLI, K8s 매니페스트, NetConf 또는 테라폼 중 하나를 선택해 수행된다.

물리적 라우터 대신 컨테이너 어플라이언스를 사용하면 일반적으로 약간의 운영 오버헤드가 발생하지만 J-CNR은 K8s CNI와 오퍼레이터 프레임워크를 사용해 이를 완화한다.

적절한 디바이스 인터페이스를 노출함으로써 J-CNR은 가상 어플라이언스의 운영 모델을 물리적 어플라이언스로 정규화해 오퍼레이터의 네트워크 운영 환경 내 도입을 촉진한다.

J-CNR은 또한 하드웨어 기반 플랫폼과 동일한 사양, 기능, 운영 모델을 제공하므로 기존 주니퍼 교육을 받은 운영 팀에게 익숙한 룩앤필(Look and Feel)을 제공한다.

마찬가지로 도메인 컨트롤러는 J-CNR 통신 및 제어를 위해 다른 주노스 라우터와 함께 지원하는 Netconf/OpenConfig, gRPC, PCEP, pRPD(Programmable Routing Protocol Daemon) API 등의 프로토콜을 사용할 수 있다.

라우팅 시스템 내 노드 역할은

네트워크 라우팅 시스템 내에서 노드는 ISIS 또는 OSPF에 참여한다. 또한 흔히 SR(Segment Routing)을 기반으로 하는 MPLS가 사용된다. 그 이유는 두 가지다. 트래픽 엔지니어링(필요한 경우)을 허용하고 MPLS 기반 레이어 3 VPN을 제공하기 위해서다. 또는 SRv6를 사용하는 방법도 있다.

네트워크 슬라이싱을 구현하려면 포괄적인 라우팅 기능도 필요하다. 각 슬라이스는 자체 레이어 3 VPN에 배치되고 J-CNR은 레이어 3 VPN 관점에서 PE 역할을 한다. 따라서 PE가 물리적 라우터인지 아니면 다른 호스트에 있는 클라우드 네이티브 라우터인지에 관계없이 네트워크의 다른 PE 라우터와 BGP를 통해 레이어 3 VPN 프리픽스를 교환한다.

각 슬라이스는 각 PE의 별도 VRF(Virtual Routing and Forwarding) 테이블에 배치돼 기존 레이어 3 VPN 서비스와 마찬가지로 슬라이스 간에 적절한 수준의 격리 및 보안을 제공한다.

이 기능은 K8s가 이러한 격리를 기본 제공하지 않는 문제에 대한 솔루션을 제공한다. 일반적으로 전송 네트워크는 최소 지연 또는 고대역폭과 같은 특정 비용함수에 맞게 조정된 다양한 경로를 제공한다. 이들은 SR 플렉스-알고(flex-algo), RSVP 또는 SR 기반 트래픽 엔지니어링을 사용해구현된다.

트래픽 엔지니어링을 사용하는 경우 주니퍼 파라곤 패스파인더 컨트롤러에서 경로를 계산하고 PCEP를 통해 J-CNR에 전달할 수 있다. 패스파인더가 스트리밍 텔레메트리를 통해 네트워크 혼잡을 감지하면 영향을 받는 경로를 자동으로 다시 계산해 정체를 완화시킨다.

J-CNR을 포함한 PE 라우터는 해당 슬라이스가 필요로 하는 경로 유형에 따라 주어진 VRF의 프리픽스에 태그(BGP Color Communities)를 적용한다. 예를 들어 아래 <그림 4>에서 빨간색 슬라이스는 가능한 최단 지연 전송이 필요하므로 EDC(Edge Data Center)의 O-CU에 도달하기 위해 파란색 저지연 경로에 매핑된다.

노란색 및 녹색 슬라이스에는 고대역폭이 필요하므로 트래픽이 보라색 고대역폭 경로에 매핑된다. 다이어그램에 표시된 것보다 더 많은 슬라이스가 있는 실제 구축에서는 슬라이스를 전송 경로에 매핑하는 것이 일반적으로 다대일(many-to-one)이다.

이에 따라 지정된 엔드포인트 쌍 간에 저지연 전송이 필요한 모든 슬라이스는 두 엔드포인트를 연결하는 동일한 저지연 트래픽 엔지니어링 또는 플렉스-알고 경로를 공유한다.

J-CNR은 CNF(Containerized Network Function)를 호스팅하는 서버 플랫폼에 세계 정상급 주노스 라우팅의 모든 기능을 구현한다. 이를 통해 해당 플랫폼이 오퍼레이터의 네트워크 라우팅 시스템에 완전히 참여하고 멀티 테넌시 및 네트워크 슬라이싱을 지원할 수 있다.

J-CNR은 또한 익숙한 룩앤필을 갖고 있으며 주노스 하드웨어 기반 라우터와 동일한 컨트롤 플레인 인터페이스로 일관된 운영 경험을 제공한다. 따라서 네트워크 오퍼레이터는 기존 인프라와의 운영 일관성을 유지하면서 운영비용 절감, 비즈니스 민첩성, 캐리어급 안정성과 같은 클라우드 네이티브 네트워킹 모델의 혁신적인 이점을 누릴 수 있다.