Neal Weinberg, Johna Till Johnson | Network World

MPLS(Multi-Protocol Label Switching)의 핵심은 서비스가 아니라 기술이며, IP VPN부터 메트로 이더넷에 이르기까지 온갖 기능을 제공할 수 있다. 하지만 MPLS는 값이 비싸다. 따라서 SD-WAN(Software-Defined WAN)의 등장과 함께 기업들은 인터넷과 같은 덜 비싼 연결을 사용할지, MPLS 사용을 최적화해야 할지를 두고 고심하고 있다.

Credit: Getty Images Bank

온라인으로 물건을 주문하고 배송 추적을 해보니 전국 곳곳을 경유하는 이해할 수 없고 비논리적이기까지 한 경로를 통해 배송되는 모습을 본 적이 있을 것이다.

인터넷의 IP 라우팅도 비슷하다. 인터넷 라우터가 받는 IP 패킷에는 목적지 IP 주소 이외에는 아무런 정보도 없다. 이 패킷을 목적지까지 어떻게 전달해야 하는지, 그 과정에서 패킷을 어떻게 취급해야 하는지에 대한 지침이 없다.

각 라우터는 오로지 패킷의 네트워크 계층 헤더만 보고 각 패킷에 대해 독립적인 포워딩 결정을 내려야 한다. 따라서 패킷이 라우터에 도착할 때마다 라우터는 패킷을 보낼 다음 지점을 "생각"해야 한다. 라우터는 이 작업을 위해 복잡한 라우팅 테이블을 참조한다.

이 과정은 패킷이 최종적으로 목적지에 도착할 때까지 경로를 따라 매 홉(hop)에서 반복된다. 모든 홉, 모든 라우팅 결정을 거치느라 화상 회의나 IP 전화(VoIP)와 같은 시간에 민감한 애플리케이션에서 사용하기에는 성능이 너무 떨어지게 된다.

MPLS란 무엇인가
세기의 전환기에 등장한 유서깊은 WAN의 강력한 도구, 멀티 프로토콜 레이블 스위칭인 MPLS은 미리 결정된 고효율 경로를 설정하는 방법으로 성능 문제를 해결한다. MPLS에서는 패킷이 처음 네트워크로 진입할 때 특정 FEC(Forwarding Equivalence Class)에 할당된다. FEC는 패킷에 첨부된 짧은 비트 시퀀스(레이블)로 표시된다.

네트워크의 각 라우터에는 특정 FEC 유형의 패킷을 어떻게 처리할지 나타내는 테이블이 있으므로 일단 패킷이 네트워크에 진입하면 라우터는 헤더 분석을 할 필요가 없다. 대신 후속 라우터는 이 레이블을 패킷에 대한 새 FEC를 제공하는 테이블의 인덱스로 사용한다.

이는 MPLS 네트워크는 일정한 특징을 가진 패킷(예를 들어 특정 포트에서 오거나 특정 애플리케이션 유형의 트래픽을 나르는 패킷)을 일관적으로 처리하는 기능을 부여한다. 음성 또는 비디오와 같은 실시간 트래픽을 나르는 패킷을 네트워크의 저지연 경로로 손쉽게 매핑할 수 있다. 전통적인 라우팅에서는 어려운 일이다.

아키텍처의 핵심은 레이블이 각 패킷에 부가적인 정보, 과거의 라우터가 가졌던 정보보다 더 많은 정보를 추가하는 방편을 제공한다는 것이다.

MPLS의 작동 방식
MPLS의 강점은 특정 기반 기술에 묶이지 않는다는 데 있다. MPLS는 ATM과 프레임 릴레이의 시대에 간소화와 성능 개선을 위한 오버레이 기법으로 설계됐다(MP, 즉 "멀티 프로토콜"에 해당하는 부분이다).

ATM과 프레임 릴레이는 이제 오래된 기억 속에 존재하지만 MPLS는 통신사 백본과 기업 네트워크에 여전히 살아 있다. 가장 일반적인 사용 사례는 실시간 애플리케이션을 위한 서비스 품질(QoS)이 필요한 지사 사무실, 캠퍼스 네트워크, 메트로 이더넷 서비스 및 기업이다.

MPLS는 2계층인가, 3계층인가
MPLS가 2계층 서비스인지, 3계층 서비스인지를 두고 많은 혼란이 있다. 그러나 MPLS는 OSI 7계층 구조에 딱 들어맞지 않는다. 사실 MPLS의 핵심적인 장점 가운데 하나는 포워딩 메커니즘을 기반 데이터 링크 서비스에서 분리한다는 데 있다. 즉, MPLS를 사용하면 어느 기반 프로토콜에서든 포워딩 테이블을 만들 수 있다.

구체적으로 보면 MPLS 라우터는 FEC의 조건을 기반으로 MPLS 네트워크의 트래픽을 라우팅하기 위한 사전 결정된 경로인 LSP(label-switched path, 레이블 전환 경로)를 설정한다. MPLS 포워딩은 LSP가 설정된 이후에만 가능하다. LSP는 단방향이다. 즉, 돌아오는 트래픽은 다른 LSP로 전송된다.

최종 사용자가 MPLS 네트워크로 트래픽을 보내면 네트워크 에지에 위치하는 입구 MPLS 라우터가 레이블을 추가한다. 이 MPLS 레이블은 다음과 같은 4개의 하위 요소로 구성된다.

- 레이블(Label) : 레이블에는 MPLS 라우터에서 패킷을 포워딩해야 할 위치를 결정하기 위한 모든 정보가 포함된다.

- 익스페리멘탈(Experimental) : 익스페리멘탈 비트는 QoS에서 레이블이 있는 패킷에 적용할 우선 순위를 설정하는 데 사용된다.

- 바텀 오브 스택(Bottom-of-Stack) : 바텀 오브 스택은 MPLS 라우터에 여기가 여정의 마지막 레그인지, 더 이상 관련된 레이블이 없는지 여부를 알려준다. 그렇다면 보통은 그 라우터가 출구 라우터가 된다.

- 타임 투 리브(Time-To-Live) : 패킷을 버리기 전까지 가능한 홉 횟수를 식별한다.

MPLS의 장단점
MPLS의 장점은 확장성, 성능, 더 효율적인 대역폭 활용, 네트워크 혼잡 감소, 최종 사용자 경험 향상이다.

MPLS 자체는 암호화를 제공하지 않지만 VPN(Virtual Private Network)이므로, 공용 인터넷에서 따로 떨어져 작동한다. 따라서 MPLS는 안전한 전송 모드로 간주된다. 또한 순수 IP 기반 네트워크에 타격을 입힐 수 있는 서비스 거부 공격에 취약하지 않다.

단점도 있다. MPLS는 통신사로부터 구매해야 하는 서비스이며 공용 인터넷을 통해 트래픽을 보내는 것보다 훨씬 더 많은 비용이 든다.

기업은 새로운 시장으로 사업을 확장할 때 글로벌 서비스 범위를 제공하는 MPLS 서비스 공급자를 찾는 데 어려움을 겪을 수 있다. 일반적으로 서비스 공급자는 다른 서비스 공급자와의 파트너십을 통해 상호 서비스 범위를 연결하는 방법을 사용하므로 비용이 높다.

또한 MPLS는 지사 사무실이 본사 또는 데이터센터로 트래픽을 돌려보냈던 시절에 만들어졌다. 지금 세계에서는 지사 사무실 근무자들이 클라우드에 대한 직접 액세스를 원한다.

MPLS는 죽었는가
지난 2013년, 가트너는 이런 도발적인 질문을 던졌고, MPLS가 WAN 환경의 핵심 요소로서 계속 운용되겠지만 대부분의 기업은 MPLS 네트워크와 공용 인터넷으로 구성된 하이브리드 환경으로 서서히 전환할 것이라는 예측으로 스스로 답했다.

MPLS는 대규모의 지역 사무실, POS 시스템을 갖춘 소매 설비, 지역 제조 설비, 여러 데이터센터와 같이 특정 점 대 점 위치를 연결하는 역할을 계속 수행하게 된다. 또한 실시간 애플리케이션에도 필요하다.

그러나 기업 WAN 설계자들은 MPLS의 최상급 성능과 높은 비용, 그리고 인터넷의 다소 불안정한 성능과 저렴한 비용 사이에서 위험과 보상을 계산해야 한다. 여기서 바로 흥미진진한 신기술, SD-WAN이 개입한다.

MPLS 대 SD-WAN
과장된 선전만 보면 값싸고 유연한 SD-WAN이 느린 공룡인 MPLS를 몰아낼 기세다. 그러나 사실 두 기술 모두 현대의 WAN에서 각자의 역할이 있다. SD-WAN은 소프트웨어 정의 네트워킹(SDN) 개념을 WAN에 적용한 것이다. SD-WAN 에지 기기를 배포해 최선의 경로에 따라 트래픽을 전송하기 위한 규칙과 정책을 적용한다.

SD-WAN은 MPLS를 포함한 모든 유형의 트래픽을 라우팅할 수 있는, 전송 방식에 무관한 오버레이다. SD-WAN의 장점은 기업 WAN 트래픽 설계자가 중앙에서 모든 WAN 기기에 손쉽게 정책을 적용할 수 있다는 점이다.

반면 MPLS의 사전 결정된 경로는 힘들게 준비해야 하고 고정된 경로가 올라가면 이후 변경하기가 쉽지 않다.

그러나 일단 구축된 MPLS 네트워크는 실시간 트래픽을 위한 보장된 성능을 제공한다. SD-WAN은 가장 효율적인 경로로 트래픽을 라우팅할 수 있지만 IP 패킷이 개방된 인터넷에 도달하는 순간부터 성능 보장이 되지 않는다.

가장 합리적인 전략은 최대한 많은 MPLS 트래픽을 공용 인터넷으로 덜어내면서 전달 보장이 필요한, 시간에 민감한 애플리케이션에는 계속 MPLS를 사용하는 것이다. CEO와 지사 직원들 간의 월별 화상 회의가 중간에 끊어질 때, 누구도 그 사태를 책임지고 싶지는 않을 것이다. editor@itworld.co.kr  

원문보기: http://www.itworld.co.kr/news/108621#csidx27ab07b4aa044f3a86faebc04fa332f