KR20150050447A

KR20150050447A - Bgp 라우팅에 대한 장애 처리 방법

Info

Publication number: KR20150050447A
Application number: KR1020140148122A
Authority: KR
Inventors: 곽은주; 이광국; 이영욱; 이호송
Original assignee: 주식회사 케이티
Priority date: 2013-10-29
Filing date: 2014-10-29
Publication date: 2015-05-08
Also published as: KR101589384B1

Abstract

BGP 라우팅에서 발생하는 장애를 처리하기 위한 방법이 개시된다. BGP 라우팅에 대한 장애 처리 방법은, 적어도 하나의 라우터와 컨트롤러로 구성된 BGP 라우팅 시스템에서 장애를 처리하는 방법에 있어서, 제1 BGP 라우터가 제2 BGP 라우터로부터 업데이트 메시지를 수신하는 단계와; 제1 BGP 라우터가 업데이트 메시지를 검증하여 에러 유형을 판단하는 단계와; 제1 BGP 라우터가 에러 유형에 관한 정보를 컨트롤러로 전송하는 단계와; 제2 BGP 라우터가 에러 유형에 관한 정보에 기반한 컨트롤러의 제어에 따라 에러를 복구하는 단계를 포함한다. 따라서, 컨트롤러를 이용하여 BGP 라우터의 장애에 대해 개선된 에러 처리를 통해 BGP 라우팅의 안정성, 확장성, 신뢰성을 개선할 수 있다.

Description

BGP 라우팅에 대한 장애 처리 방법{METHOD OF FAILOVER FOR BGP ROUTING}

본 발명은 소프트웨어 정의 네트워킹에 관한 것으로, 더욱 상세하게는 BGP 라우팅에서 발생하는 장애를 처리하기 위한 방법에 관한 것이다.

통신 네트워크의 유연한 제어와 비용절감을 위해 통신 시스템의 전달 평면(forwarding plane)과 제어 평면(control plane)을 독립적으로 분리하여, 소프트웨어 프로그래밍을 하듯 네트워크를 중앙에서 소프트웨어적으로 정의하고 제어할 수 있는 소프트웨어 정의 네트워크(SDN, software defined networking) 기술이 등장하였다.

이러한 흐름에 따라 IETF에서는 기존 라우터의 기능을 최대한 수정없이 SDN 개념을 적용할 수 있도록 외부의 컨트롤러를 이용하여 중앙집중식으로 라우터 정보를 수집하거나, 라우팅 시스템 제어 정책을 적용할 수 있도록 하는 라우터와 외부 컨트롤러의 표준 인터페이스를 정의하고 있다.

한편, BGP(Border Gateway Protocol)는 원래 AS(autonomous system)간 라우팅을 위한 EGP(External Gateway Protocol)로 사용되었으나, 점차 iBGP 로 사용됨으로써, 현재 IP 네트워크에서 inter-AS 와 intra-AS 에서 중요한 routing protocol로 사용되고 있다.

또한, BGP는 IP, L2VPN, L3VPN 등과 같은 다양한 IP/MPLS 서비스에 대한 reachability 정보를 제공한다. 따라서, BGP 세션(session)의 장애는 고객 서비스의 중단 등과 같은 심각한 영향을 발생시킬 수 있기 때문에, BGP의 강인성과 신뢰성에 대한 요구가 증대되고 있다.

BGP의 동작은 각 AS내의 BGP 이웃 라우터들간에 peer를 맺고 각 이웃 라우터들간에 정보를 주고 받으며 수행된다.

따라서, BGP의 에러에 대한 처리는 이웃 라우터들과의 일관성을 보장하고, 두 개의 이웃 라우터들 사이의 정보의 수정하는 것이 필요하다.

그러나, SDN 환경에서 BGP의 에러에 대한 처리를 위한 절차 또는 방법에 대한 연구가 미흡한 실정이다.

상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, SDN 환경에서 BGP의 에러에 대한 처리 방법을 제공하는데 있다.

상기 목적을 달성하기 위한 본 발명의 일 측면에 따른 BGP 라우팅에 대한 장애 처리 방법은, 적어도 하나의 라우터와 컨트롤러로 구성된 BGP 라우팅 시스템에서 장애를 처리하는 방법에 있어서, 제1 BGP 라우터가 제2 BGP 라우터로부터 업데이트 메시지를 수신하는 단계와; 제1 BGP 라우터가 업데이트 메시지를 검증하여 에러 유형을 판단하는 단계와; 제1 BGP 라우터가 에러 유형에 관한 정보를 컨트롤러로 전송하는 단계와; 제2 BGP 라우터가 에러 유형에 관한 정보에 기반한 컨트롤러의 제어에 따라 에러를 복구하는 단계를 포함한다.

여기에서, 상기 업데이트 메시지는, NLRI(Network Layer Reachability Information), NLRI의 특성을 표현하는 Path Attribute 및 삭제된 경로 정보인 Withdrawn Route Information을 포함할 수 있다.

여기에서, 상기 에러 유형을 판단하는 단계는, 업데이트 메시지로부터 NLRI(Network Layer Reachability Information)의 특성을 추출하지 못하거나 파싱(Parsing)하지 못하는 경우를 치명적 에러(Critical error)로 판단하고, 업데이트 메시지로부터 NLRI의 특성을 추출할 수 있는 경우를 비치명적 에러(Non-Critical error)로 판단할 수 있다.

여기에서, 상기 에러 유형이 상기 치명적 에러인 경우, 제1 BGP 라우터는 RIB(Routing Information Base)에 대한 업데이트를 보류하고, 상기 에러 유형이 상기 비치명적 에러인 경우, 제1 BGP 라우터는 제2 BGP 라우터와의 세션(Session)을 끊을 수 있다.

여기에서, 상기 에러를 복구하는 단계는, 에러 유형이 상기 치명적 에러인 경우, 제2 BGP 라우터가 상기 컨트롤러에 의한 세션 레벨 복구(Session Level Recovery) 요청에 따라 제1 BGP 라우터와 세션을 재설정할 수 있다.

여기에서, 상기 에러를 복구하는 단계는, 에러 유형이 상기 비치명적 에러인 경우, 제2 BGP 라우터가 컨트롤러에 의한 RIB(Routing Information Base) 일관성 복구(Consistency Recovery) 요청에 따라 업데이트 메시지를 복원하여 제1 BGP 라우터로 재전송할 수 있다.

여기에서, 상기 방법은, 컨트롤러가 에러 유형에 관한 정보를 포함하는 에러 이벤트 정보를 컨트롤러에 수용된 네트워크 애플리케이션에 전달하여 BGP 라우팅 시스템의 운용자에 에러 발생을 알리는 단계를 더 포함할 수 있다.

상기 목적을 달성하기 위한 본 발명의 다른 측면에 따른 BGP 라우팅에 대한 장애 처리 방법은, 제1 BGP 라우터와 제2 BGP 라우터가 피어(Peer)를 구성하는 BGP 라우팅 시스템에서 장애를 처리하는 방법에 있어서, 컨트롤러가 제1 BGP 라우터로부터 에러 유형에 관한 정보를 포함하는 에러 이벤트 정보를 수신하는 단계와; 컨트롤러가 에러 유형에 관한 정보를 이용하여 제1 BGP 라우터와 제2 BGP 라우터 사이에 발생한 에러 유형을 판단하는 단계와; 컨트롤러가 에러 유형에 관한 정보에 기반하여 제2 BGP 라우터에 에러 복구를 수행시키는 단계를 포함한다.

여기에서, 상기 에러 유형은, 치명적 에러(Critical error)와 비치명적 에러(Non-Critical error)로 구분될 수 있다.

여기에서, 상기 치명적 에러는, 제2 BGP 라우터로부터 제1 BGP 라우터로 전송되는 업데이트 메시지로부터 NLRI(Network Layer Reachability Information)의 특성을 추출하지 못하거나 파싱(Parsing)하지 못하는 경우이고, 상기 비치명적 에러는, 제2 BGP 라우터로부터 제1 BGP 라우터로 전송되는 업데이트 메시지로부터 NLRI의 특성을 추출할 수 있는 경우일 수 있다.

여기에서, 상기 에러 유형이 상기 치명적 에러인 경우, 제1 BGP 라우터는 RIB(Routing Information Base)에 대한 업데이트를 보류하고, 상기 에러 유형이 상기 비치명적 에러인 경우, 제1 BGP 라우터는 상기 제2 BGP 라우터와의 세션(Session)을 끊을 수 있다.

여기에서, 상기 에러를 복구하는 단계는, 에러 유형이 상기 치명적 에러인 경우, 컨트롤러가 제2 BGP 라우터에 세션 레벨 복구(Session Level Recovery)를 요청하여 제2 BGP 라우터가 상기 제1 BGP 라우터와 세션을 재설정하도록 할 수 있다.

여기에서, 상기 에러를 복구하는 단계는, 에러 유형이 상기 비치명적 에러인 경우, 컨트롤러가 제2 BGP 라우터에 RIB(Routing Information Base) 일관성 복구(Consistency Recovery)를 요청하여 업데이트 메시지를 복원시키고, 복원된 업데이트 메시지를 제1 BGP 라우터로 재전송하도록 할 수 있다.

여기에서, 상기 방법은, 컨트롤러가 에러 이벤트 정보를 컨트롤러에 수용된 네트워크 애플리케이션에 전달하여 BGP 라우팅 시스템의 운용자에 에러 발생을 알리는 단계를 더 포함할 수 있다.

상기와 같은 본 발명에 따른 BGP 라우팅에 대한 장애 처리 방법은, 컨트롤러를 이용하여 BGP 라우터의 장애에 대해 개선된 에러 처리를 통해 BGP 라우팅의 안정성, 확장성, 신뢰성을 개선할 수 있다.

또한, 네트워크 운용자가 필요로 하는 BGP 라우팅 에러에 관한 이벤트 정보를 쉽게 모니터링하여 장애 원인 분석 등과 같은 다양한 응용에 적용할 수 있다.

또한, 컨트롤러를 통해 자신의 AS내 BGP 라우터 뿐만 아니라 서로 다른 AS들간에 동작하는 BGP 라우팅 에러에 대한 정보를 빠르게 서로 공유할 수 있다.

또한, Inband BGP 채널이 아닌 별도의 컨트롤러와의 인터페이스를 사용함으로써, BGP 운용에 영향을 최소화한 상태에서 에러를 처리할 수 있다.

도 1은 본 발명의 실시예에 따라 컨트롤러에 의해 제어되는 BGP 라우팅 시스템을 설명하기 위한 예시도이다.
도 2는 본 발명의 실시예에 따른 비치명적 에러를 처리하는 방법을 설명하기 위한 예시도이다.
도 3은 본 발명의 실시예에 따른 치명적 에러를 처리하기 위한 방법을 설명하기 위한 예시도이다.
도 4는 본 발명의 실시예에 따른 BGP 라우팅 시스템을 위한 에러 처리 방법을 설명하기 위한 예시도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 본 발명에서 언급되는 '컨트롤러(controller)'는 트래픽의 흐름을 제어하기 위해 관련 구성 요소(예를 들면, 스위치, 라우터 등)를 제어하는 기능 요소(entity)를 의미하는 것으로, 물리적인 구현 형태나 구현 위치 등에 한정되지 않는다. 예를 들어, 컨트롤러는 ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 컨트롤러 기능 요소(entity)를 의미할 수 있다.

또한, 본 발명에서 언급되는 '라우터' 또는 '네트워크 장비'는 트래픽(또는 패킷)을 실질적으로 포워딩하거나 스위칭 또는 라우팅하는 기능 요소를 의미하는 것으로, ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 스위치, 라우터, 스위치 요소, 라우터 요소, 포워딩 요소 등을 의미할 수 있다.

또한, 이하에서 기술되는 본 발명의 실시예들은 SDN 기술의 표준화를 수행하고 있는 ONF, IETF, ETSI, ITU-T들에서 작성된 표준 문서들 및/또는 전달 네트워크에 관한 표준화를 수행하는 IEEE, ITU-T, IETF들에서 작성된 표준 문서들에 의해 뒷받침될 수 있다. 즉, 본 발명의 실시예들 중 본 발명의 기술적 사상을 명확히 드러내기 위해 구체적으로 설명하지 않은 내용들은 상기의 표준화 단체들에서 작성한 표준 문서들에 의해 뒷받침될 수 있다. 또한, 본 발명에서 사용되는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다.

이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

도 1은 본 발명의 실시예에 따라 컨트롤러에 의해 제어되는 BGP 라우팅 시스템을 설명하기 위한 예시도이다.

도 1를 참조하여, 외부 컨트롤러에 의해 BGP 라우터의 제어 평면이 제어되는 BGP 라우팅 시스템의 구조를 설명한다.

본 발명의 실시예에 따른 BGP 라우팅 시스템은 서로 다른 AS에 속한 BGP 라우터 A(210)와 BGP 라우터 B(220) 및 라우터와 물리적으로 분리되어 있는 외부 컨트롤러(100)를 포함하여 구성된다.

또한, BGP 라우팅 시스템은 라우터의 제어 평면 상에 존재하는 Agent 모듈(211, 221)과 컨트롤러의 Client 모듈(101) 상호 간에 표준화된 라우팅 시스템 인터페이스(I2RS, Interface to Routing System)을 통해 상호 통신이 되는 구조를 가질 수 있다.

Agent 모듈(211, 221), BGP 모듈(212, 222), Topology DB(213, 223), Routing information base 모듈(214, 224) 및 Policy DB(215, 225) 및 OAM event 모듈(216, 226)가 BGP 라우터(210, 220)의 제어 평면 상에 포함할 수 있다.

또한, Forwarding information base 모듈(217, 227)은 라우터(210, 210)의 데이터 평면 상에 존재할 수 있다. 따라서, 라우팅 프로토콜에 의해 업데이트된 정보는 Routing information base 모듈(214, 224)을 거쳐 데이터 평면의 Forwarding information base 모듈(217, 227)로 전달될 수 있다.

한편, 컨트롤러(100)는 컨트롤러(100)가 제공하는 Northbound API를 통해 다양한 Network Application(300)을 지원할 수 있다. 예를 들어, Network Application은 컨트롤러에 의해 수신된 이벤트를 모니터링할 수 있는 Event Monitoring App. 일 수 있다. .

먼저, 본 발명의 실시예에 따른 BGP 라우팅 시스템에서 수행되는 BGP 동작의 기본적인 개념을 설명하면 다음과 같다.

BGP는 AS간에 라우팅 정보(Routing Information)를 교환하는 데 사용된다. BGP는 동작을 위해 기본적으로 다음과 같은 4개의 메시지를 사용할 수 있다.

● Open Message

- TCP session이 이루어진 후 최초로 BGP 라우터 간의 Neighbor 형성을 위해 사용되는 Message

● Update Message

- 각 Network 정보와 각 Network를 Loop-Free 하게 하기 위한 각종 정보를 포함

- NLRI(network Layer Reachability Information), Path Attribute를 포함

● Keepalive Message

- 주기적인 Neighbor 사이의 연결(Connection)을 확인하기 위한 Message

● Notification Message

- Neighbor와의 각종 Error 정보를 알리기 위한 Message

BGP 라우터(210, 220)는 Open Message를 이용하여 BGP 라우터(210, 220) 간의 Neighbor를 형성할 수 있다.

Neighbor를 형성한 후에, BGP 라우터(210, 220)는 주기적으로 피어(Peer)의 상태를 체크하기 위해 Keepalive Message를 교환할 수 있다.

또한, BGP 라우터(210, 220)는 Update Message를 이용하여 AS간에 라우팅 정보(Routing information)를 교환할 수 있다.

일반적으로 BGP 라우터(210, 220)는 에러가 있는 Update Message를 수신하면 notification message를 송신하고, 에러가 관찰된 상대 라우터와 adjacency를 끊는 것으로 규격이 정해져 있다. 그러나 이러한 오류 처리(Error Handling)는 현재 BGP의 역할 변화에 따른 고객 서비스의 중단 등과 같은 심각한 영향을 줄 수 있다. 따라서, 오류 처리로 인한 서비스의 중단을 최소화하고 신뢰성을 개선하는 메커니즘이 필요하다.

또한, BGP는 서로 다른 AS간에 에러가 발생한 경우 해당 네트워크 운용자에게 에러를 통보하기 위해서 상대 BGP 라우터에게 에러가 발생했다는 정보를 알려줄 필요가 있으나, 서로 다른 로깅 시스템을 사용함으로 이러한 정보를 효율적으로 교환하기 어렵다.

본 발명의 실시예에 따르면, BGP 라우터가 업데이트 메시지(Update Message)를 수신하여 에러로 판단할 때 에러의 유형과 심각성에 따라 에러 유형을 구분하여 에러를 처리하는 방법을 제안한다.

Update Message는 Update 메시지에 포함된 NLRI 정보의 특성을 표현하는 데 사용되는 Path Attribute와 NLRI, 삭제된 경로 정보인 Withdrawn Route Information와 같은 3가지 정보를 포함할 수 있다. Update Message를 수신하여 에러로 판단할 때 에러의 심각성과 유형에 따라 아래와 같이 치명적 에러(Critical error)와 비치명적 에러(Non-Critical error)로 구분하여 처리하는 방법을 제안한다.

본 발명의 실시예에 따른 BGP 라우팅에 대한 장애 처리 방법은 Update Message를 수신하여 에러로 판단할 때, 에러의 심각성에 따라 에러 유형을 구분하여 에러를 처리하는 방법을 제공한다.

Update Message는 NLRI(Network Layer Reachability Information), NLRI의 특성을 표현하는 Path Attribute 및 삭제된 경로 정보인 Withdrawn Route Information와 같은 3가지 정보를 포함할 수 있다.

Update Message에 따른 에러 유형은 치명적 에러(Critical error)와 비치명적 에러(Non-Critical error)로 구분될 수 있다.

먼저, 치명적 에러는 Update Message에서 NLRI의 특성(NLRI attribute)을 추출하지 못하거나 파싱(parsing)하지 못하는 경우로, 예를 들어 다음과 같은 경우를 의미할 수 있다.

- Update Message Length error: Total Path Attribute와 Withdrawn Routes length의 합이 불일치하는 경우

- Message packing와 framing에서 에러 발생한 경우 등과 같이 NLRI attribute를 정확하게 추출할 수 없는 경우

- NLRI attribute의 parsing Errors: IP V4 Unicast Advertised, Withdrawn Routes attributes, MP_REACH_LNRI, MP-UNREACH-NLRI의 내용을 파싱할 수 없을 경우

다음으로, 비치명적 에러는 Update Message에서 NLRI attribute를 추출할 수 있는 경우로, 예를 들어 다음과 같은 경우를 의미할 수 있다.

- Path attributes에서 NLRI를 제외하고 0이거나, Path attributes에서 invalid length errors가 있는 경우

- 모든 Path attributes의 길이가 total attribute length와 일치하지 않는 경우

- NLRI와 관계되지 않은 Path attribute에 Invalid data 또는 flags가 포함된 경우

- UPDATE Message가 Missing Mandatory attributes, unrecognized non-optional attributes, 중복 또는 invalid attributes를 포함하는 경우

- NEXT HOP, MP_REACH_NLRI next-hop values 값이 없거나, zero - length 또는 관련된 address family가 유효하지 않은 경우

도 2는 본 발명의 실시예에 따른 비치명적 에러를 처리하는 방법을 설명하기 위한 예시도이다.

도 2를 참조하면, 서로 다른 AS에 속한 라우터 A(210)와 라우터 B(220)는 eBGP Peer를 형성하여 Update Message를 주고 받을 수 있다.

라우터 B(220)가 비치명적 에러에 해당하는 Update Message를 라우터 A(210)로 송신한 경우의 에러 처리에 대해 설명한다.

먼저, 라우터 A(210)는 라우터 B(220)로부터 Update Message를 수신할 수 있다(S310).

라우터 A(210)는 수신한 Update Message를 검증하여 에러 유형을 분류한다.

라우터 A(210)는 에러 유형을 비치명적 에러로 분류하고, 에러 유형에 대한 정보를 포함하는 Error Event를 컨트롤러(100)로 전송할 수 있다(S320).

여기서, Error Event는 다음과 같은 정보를 포함할 수 있다.

- NLRI, 수신한 UPDATE Message 원본

- 수신시간, Error Code, 기타 통보가 필요한 정보

또한, 라우터 A(210)는 비치명적 에러에 해당하는 Update Message를 수신한 경우, RIB(Routing Information Base)를 업데이트하지 않고 보류를 하며, 다음 업데이트시에 정상적인 Update Message를 수신할 때 RIB를 업데이트할 수 있다.

컨트롤러(100)는 Error Event에 대한 정보를 Network Application(300)에 전달하여 네트워크 운영자(Network Operator)에 에러의 발생 등을 알릴 수 있다(S330). 여기서, Network Application(300)는 Event Monitoring Application 일 수 있다.

보다 상세하게는, 비치명적 에러에 대한 처리로 인해 라우터 A(210)와 라우터 B(220)의 RIB사이에 불일치(Inconsistency)가 발생할 수 있고, 이로 인하여 Traffic의 Looping이나 Black-holing이 발생할 수 있으므로 네트워크 운용자에게 에러의 발생 등에 대한 정보를 알리는 것이 필요하다. 즉, Event Monitoring Application은 네트워크 운영자에게 Error Event를 알릴 수 있다.

컨트롤러(100)는 Update Message에 대한 에러 복구 요청인 RIB 일관성 복구 요청(Consistency Recovery Request)을 할 수 있다(S340).

여기서, S330과 S340은 반드시 순차적으로 수행되어야 하는 것은 아니고, 동시에 또는 임의의 순서로 수행될 수 있다.

라우터 B(200)는 RIB 일관성 복구 요청에 따라 메시지 레벨 복구를 수행할 수 있다(S350). 메시지 레벨 복구는 해당 세션은 유지하면서 Update Message를 다시 formatting하여 재전송하는 것으로서, route refresh, re-advertisement 등과 같은 복구 메커니즘(recovery mechanism)에 의해 수행될 수 있다.

도 3은 본 발명의 실시예에 따른 치명적 에러를 처리하기 위한 방법을 설명하기 위한 예시도이다.

도 3을 참조하면, 서로 다른 AS에 속한 라우터 A(210)와 라우터 B(220)는 eBGP Peer를 형성하여 Update Message를 주고 받을 수 있다.

라우터 B(220)가 치명적 에러에 해당하는 Update Message를 라우터 A(210)로 송신한 경우의 에러 처리에 대해 설명한다.

먼저, 라우터 A(210)는 라우터 B(220)로부터 Update Message를 수신할 수 있다(S410).

라우터 A(210)는 에러 유형을 치명적 에러로 분류하고, 에러 유형에 대한 정보를 포함하는 Error Event를 컨트롤러(100)로 전송할 수 있다(S420).

여기서, Error Event는 다음과 같은 정보를 포함할 수 있다.

- NLRI, 수신한 UPDATE Message 원본

- 수신시간, Error Code, 기타 통보가 필요한 정보

또한, 라우터 A(210)는 치명적 에러가 발생하였음을 알리는 Notification Message를 라우터 B(220)에 전송할 수 있고(S430), 라우터 B(220)는 라우터 A(210)와 세션(session)을 끊을 수 있다.

컨트롤러(100)는 Error Event에 대한 정보를 Network Application(300)에 전달하여 네트워크 운영자(Network Operator)에 에러의 발생 등을 알릴 수 있다(S440). 여기서, Network Application(300)는 Event Monitoring Application 일 수 있다.

보다 상세하게는, 치명적 에러에 대한 처리로 인해 라우터 A(210)와 라우터 B(220)의 RIB사이에 불일치(Inconsistency)가 발생할 수 있고, 이로 인하여 Traffic의 Looping이나 Black-holing이 발생할 수 있으므로 네트워크 운용자에게 에러의 발생 등에 대한 정보를 알리는 것이 필요하다. 즉, Event Monitoring Application은 네트워크 운영자에게 Error Event를 알릴 수 있다.

컨트롤러(100)는 라우터 B(220)에게 세션 레벨 복구(Session Level Recovery)를 요청할 수 있다(S450).

세션 레벨 복구는 현재 세션(session)을 끊고 다시 세션을 설정하는 것으로, Graceful Restart(session reset, re-establishment)와 Graceful Shutdown 등의 메커니즘을 포함할 수 있다. 따라서, 라우터 B(220)는 세션 레벨 복구 요청에 따라 라우터 A(210)와 세션을 재설정할 수 있다.

이때, 치명적 에러가 발생한 경우, 라우터 B(220)는 라우터 A(210)와 세션을 재설정을 하지 못할 수도 있다. 이런 경우를 위하여, 컨트롤러(100)는 세션 재설정에 걸리는 최대 대기 시간(SessionOpenTimer), 세션 재설정을 최대 몇 번까지 재시도할 것인지 정하는 재시도 횟수(RetryNumber) 등에 대한 정보를 포함한 미리 설정한 정책(policy)을 적용하여 세션 레벨 복구를 요청할 수 있다.

여기서, S440과 S450은 반드시 순차적으로 수행되어야 하는 것은 아니고, 동시에 또는 임의의 순서로 수행될 수 있다.

도 4는 본 발명의 실시예에 따른 BGP 라우팅 시스템을 위한 에러 처리 방법을 설명하기 위한 예시도이다.

도 4를 참조하여, 본 발명의 실시예에 따른 BGP 라우팅에 대한 장애 처리 방법을 수행하는 주체인 BGP라우터, 컨트롤러, Network Application 간의 수행되는 절차를 4 개의 단계로 설명하면 다음과 같다.

1. Session Setup 단계

Open Session(ControllerID, BGPRouterID, ASN): BGP 라우터가 컨트롤러와 세션을 열 수 있다. 이를 위해 Open Session는 컨트롤러를 구분하는 controller ID, BGP 라우터를 구분하는 BGPRouter ID, AS의 개수를 나타내는 AS Number(AS N)와 같은 파라미터를 포함할 수 있다.

Established(ControllerID, BGPRouterID, ASN): 컨트롤러가 요청한 세션에 대하여 인증하고 세션이 맺어짐을 확인(confirm)할 수 있다. 이를 위해 Established는 컨트롤러를 구분하는 controller ID, BGP 라우터를 구분하는 BGPRouter ID, AS의 개수를 나타내는 AS Number(AS N)와 같은 파라미터를 포함할 수 있다.

2. Error Classification 단계

BGP 라우터가 수신한 Update Message를 검증하여, 치명적 에러와 비치명적 에러를 분류할 수 있다. 여기서, 에러 유형에 대한 분류한 상술한 바와 같다.

3. Notification & Recovery 단계

Error Notification (CriticalYN, ErrorCode, SendRouterID, RecievedRouterID, NLRI, ReceivedTime, …): Update Message를 수신한 라우터가 Update Error에 대해 컨트롤러에게 알릴 수 있다. 이를 위해 Error Notification는 Error 유형(CriticalYN), Error Code, Update Message를 송신한 라우터 ID (SendRouterId), Update Message를 수신한 라우터 ID (ReceivedRouterId), NLRI, 메시지 수신시간(ReceivedTime) 등과 같은 Update 에러에 관한 정보를 포함할 수 있다.

Request Recovery (CriticalYN, ErrorCode, RetryNumber, SessionOpenTimer): 에러가 있는 Update Message를 수신한 라우터로부터 ErrorNotification을 받은 컨트롤러는 에러가 있는 Update Message을 송신한 라우터에게 에러 복구 요청을(RequestRecovery)을 할 수 있다. 이를 위해 Request Recovery는 에러 유형(CriticalYN), Error Code, 세션 재설정 재시도 회수(RetryNumber), 세션 재설정시 대기시간(SessionOpenTimer) 등과 같은 정보를 포함할 수 있다. 여기서, RetryNumber와 SessionOpenTimer는 치명적 에러에 따른 세션 재설정을 할 때 필요한 파라미터이며, 이를 컨트롤러는 사전에 운용자 등에 의해 설정된 값을 이용하여 에러 복구 요청을 할 수 있다.

따라서, RequestRecovery를 받은 라우터는 에러 유형에 따라 비치명적 에러인 경우는 메시지 재전송 또는 재 Framing을 하는 등과 같은 메시지 단위 복구를 수행하고, 치명적 에러인 경우 기존 세션(Session) 연결을 끊고 세션을 다시 설정하는 세션 단위 복구를 수행할 수 있다.

4. Event Information Exchange 단계

QueryEventInformation (ReceivedRouterID, SendRouterID, ASN, CriticalYN): 각기 서로 다른 ASN에 속한 라우터들이 다른 ASN의 에러 정보 등과 같은 이벤트 정보를 특정 ASN 전체 또는 특정 수신 라우터, 송신 라우터 별로 컨트롤러에게 조회 요청할 수 있다. 이를 위한 입력 변수로는 조회하고자 하는 AS 번호, 송신 라우터 ID, 수신 라우터 ID, 이벤트 유형 등이 될 수 있다.

QueryEventInformation (ReceivedRouterID, SendRouterID, ASN, CriticalYN): 컨트롤러는 특정 AS, Event Monitoring App. 또는 특정 컨트롤러에게 특정 ASN 전체 또는 특정 수신 라우터, 송신 라우터의 이벤트 정보를 조회할 수 있다. 이를 위한 입력 변수로는 조회하고자 하는 AS 번호, 송신 라우터 ID, 수신 라우터 ID, 이벤트 유형 등이 될 수 있다.

상술한 본 발명에 따른 BGP 라우팅에 대한 장애 처리 방법은, 컨트롤러를 이용하여 BGP 라우터의 장애에 대해 개선된 에러 처리를 통해 BGP 라우팅의 안정성, 확장성, 신뢰성을 개선할 수 있다.

상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

100: 컨트롤러 101: Client 모듈
210: 라우터 A 220: 라우터 B
211, 221: Agent 모듈 212, 222: BGP 모듈
213, 223: Topology DB 214, 224: Routing Info. Base 모듈
215, 225: Policy DB 216, 226: OAM Event 모듈
300: Network Application

Claims

적어도 하나의 라우터와 컨트롤러로 구성된 BGP 라우팅 시스템에서 장애를 처리하는 방법에 있어서,
제1 BGP 라우터가 제2 BGP 라우터로부터 업데이트 메시지를 수신하는 단계;
상기 제1 BGP 라우터가 상기 업데이트 메시지를 검증하여 에러 유형을 판단하는 단계;
상기 제1 BGP 라우터가 상기 에러 유형에 관한 정보를 상기 컨트롤러로 전송하는 단계; 및
상기 제2 BGP 라우터가 상기 에러 유형에 관한 정보에 기반한 상기 컨트롤러의 제어에 따라 에러를 복구하는 단계를 포함하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 1에 있어서,
상기 업데이트 메시지는,
NLRI(Network Layer Reachability Information), 상기 NLRI의 특성을 표현하는 Path Attribute 및 삭제된 경로 정보인 Withdrawn Route Information을 포함하는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 1에 있어서,
상기 에러 유형을 판단하는 단계는,
상기 업데이트 메시지로부터 NLRI(Network Layer Reachability Information)의 특성을 추출하지 못하거나 파싱(Parsing)하지 못하는 경우를 치명적 에러(Critical error)로 판단하고,
상기 업데이트 메시지로부터 상기 NLRI의 특성을 추출할 수 있는 경우를 비치명적 에러(Non-Critical error)로 판단하는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 3에 있어서,
상기 에러 유형이 상기 치명적 에러인 경우, 상기 제1 BGP 라우터는 RIB(Routing Information Base)에 대한 업데이트를 보류하고,
상기 에러 유형이 상기 비치명적 에러인 경우, 상기 제1 BGP 라우터는 상기 제2 BGP 라우터와의 세션(Session)을 끊는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 3에 있어서,
상기 에러를 복구하는 단계는,
상기 에러 유형이 상기 치명적 에러인 경우,
상기 제2 BGP 라우터가 상기 컨트롤러에 의한 세션 레벨 복구(Session Level Recovery) 요청에 따라 상기 제1 BGP 라우터와 세션을 재설정하는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 3에 있어서,
상기 에러를 복구하는 단계는,
상기 에러 유형이 상기 비치명적 에러인 경우,
상기 제2 BGP 라우터가 상기 컨트롤러에 의한 RIB(Routing Information Base) 일관성 복구(Consistency Recovery) 요청에 따라 상기 업데이트 메시지를 복원하여 상기 제1 BGP 라우터로 재전송하는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 1에 있어서,
상기 컨트롤러가 상기 에러 유형에 관한 정보를 포함하는 에러 이벤트 정보를 상기 컨트롤러에 수용된 네트워크 애플리케이션에 전달하여 상기 BGP 라우팅 시스템의 운용자에 에러 발생을 알리는 단계를 더 포함하는,
BGP 라우팅에 대한 장애 처리 방법.
제1 BGP 라우터와 제2 BGP 라우터가 피어(Peer)를 구성하는 BGP 라우팅 시스템에서 장애를 처리하는 방법에 있어서,
컨트롤러가 상기 제1 BGP 라우터로부터 에러 유형에 관한 정보를 포함하는 에러 이벤트 정보를 수신하는 단계;
상기 컨트롤러가 상기 에러 유형에 관한 정보를 이용하여 상기 제1 BGP 라우터와 상기 제2 BGP 라우터 사이에 발생한 에러 유형을 판단하는 단계; 및
상기 컨트롤러가 상기 에러 유형에 관한 정보에 기반하여 상기 제2 BGP 라우터에 에러 복구를 수행시키는 단계를 포함하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 8에 있어서,
상기 에러 유형은,
치명적 에러(Critical error)와 비치명적 에러(Non-Critical error)로 구분되는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 9에 있어서,
상기 치명적 에러는,
상기 제2 BGP 라우터로부터 상기 제1 BGP 라우터로 전송되는 업데이트 메시지로부터 NLRI(Network Layer Reachability Information)의 특성을 추출하지 못하거나 파싱(Parsing)하지 못하는 경우이고,
상기 비치명적 에러는,
상기 제2 BGP 라우터로부터 상기 제1 BGP 라우터로 전송되는 상기 업데이트 메시지로부터 상기 NLRI의 특성을 추출할 수 있는 경우인 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 10에 있어서,
상기 에러 유형이 상기 치명적 에러인 경우, 상기 제1 BGP 라우터는 RIB(Routing Information Base)에 대한 업데이트를 보류하고,
상기 에러 유형이 상기 비치명적 에러인 경우, 상기 제1 BGP 라우터는 상기 제2 BGP 라우터와의 세션(Session)을 끊는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 10에 있어서,
상기 에러를 복구하는 단계는,
상기 에러 유형이 상기 치명적 에러인 경우,
상기 컨트롤러가 상기 제2 BGP 라우터에 세션 레벨 복구(Session Level Recovery)를 요청하여 상기 제2 BGP 라우터가 상기 제1 BGP 라우터와 세션을 재설정하도록 하는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 10에 있어서,
상기 에러를 복구하는 단계는,
상기 에러 유형이 상기 비치명적 에러인 경우,
상기 컨트롤러가 상기 제2 BGP 라우터에 RIB(Routing Information Base) 일관성 복구(Consistency Recovery)를 요청하여 상기 업데이트 메시지를 복원시키고, 상기 복원된 업데이트 메시지를 상기 제1 BGP 라우터로 재전송하도록 하는 것을 특징으로 하는,
BGP 라우팅에 대한 장애 처리 방법.
청구항 9에 있어서,
상기 컨트롤러가 상기 에러 이벤트 정보를 상기 컨트롤러에 수용된 네트워크 애플리케이션에 전달하여 상기 BGP 라우팅 시스템의 운용자에 에러 발생을 알리는 단계를 더 포함하는,
BGP 라우팅에 대한 장애 처리 방법.