KR102111330B1 - 통신 네트워크에서 경로 장애 처리 방법 - Google Patents

통신 네트워크에서 경로 장애 처리 방법 Download PDF

Info

Publication number
KR102111330B1
KR102111330B1 KR1020140074011A KR20140074011A KR102111330B1 KR 102111330 B1 KR102111330 B1 KR 102111330B1 KR 1020140074011 A KR1020140074011 A KR 1020140074011A KR 20140074011 A KR20140074011 A KR 20140074011A KR 102111330 B1 KR102111330 B1 KR 102111330B1
Authority
KR
South Korea
Prior art keywords
failure
network
equipment
path
information
Prior art date
Application number
KR1020140074011A
Other languages
English (en)
Other versions
KR20150002475A (ko
Inventor
이광국
곽은주
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Publication of KR20150002475A publication Critical patent/KR20150002475A/ko
Application granted granted Critical
Publication of KR102111330B1 publication Critical patent/KR102111330B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

통신 네트워크에서 경로 장애 처리 방법이 개시된다. 제1 네트워크의 장비 및 상기 제1 네트워크의 장비와 연결된 제2 네트워크의 장비를 제어하는 컨트롤러에서 수행되는 장애 처리 방법으로, 제1 네트워크의 장비로부터 장애 발생 정보를 포함하는 장애 감지 메시지를 수신하고, 장애 발생 정보에 기초하여 장애가 발생한 경로를 판단하고 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득한 후, 장애 경로와 연관된 제2 네트워크의 장비에 장애 복구를 위한 제어 메시지를 전송한다. 따라서, 클라이언트 네트워크를 구성하는 통신 장비들이 장애 감지를 위한 기능을 지원하지 않는 경우에도 신속하게 장애를 감지할 수 있고, 감지된 장애를 신속하게 복구할 수 있다.

Description

통신 네트워크에서 경로 장애 처리 방법{METHOD FOR PROCESSING PATH FAILURE IN COMMUNICATION NETWORKS}
본 발명은 통신 네트워크에서 발생하는 경로 장애의 처리 방법에 관한 것이다.
통신 네트워크에서 현재 서비스 중인 경로에 장애가 발생했을 때, 이를 신속하게 인지하여 데이터 트래픽을 대체 경로로 빠르고 안정적으로 절체하는 것은 매우 중요하다.
전달 네트워크(transport network)에서 운용, 관리 및 유지(OAM: Operation, Administration, and Maintenance) 기능은 강력한 경로 관리 및 복구 메커니즘을 제공하는 기술로, 운용 복잡도 감소, 네트워크 가용성 향상 및 서비스 성능 관점에서 기본적이면서 중요한 기능이다.
일반적으로 전달 네트워크를 구성하는 통신 장비들은 경로 관리를 위해 주기적인 OAM 메시지를 종단간 송수신함으로써 경로의 이상 유무를 판단하고, 경로에 이상이 발생하는 경우 보호 절체(protection switching) 프로토콜을 기반으로 장애 경로의 트래픽을 미리 설정된 대체 경로로 스위칭함으로써 50ms 이내에 경로의 장애를 복구할 수 있다.
전달 네트워크 기술과 관련하여, 기존의 회선 기술인 SONET/SDH(Synchronous Optical Network/Synchronous Digital Hierarchy)을 대체하기 위한 차세대 전달 네트워크 기술로 광 전달 네트워크 기술에 대한 표준화가 이루어졌으며, 패킷 전달 네트워크 기술로는 IEEE의 PBB-TE(Provider Backbone Bridge-Traffic Engineering), ITU-T의 T-MPLS(Transport Multi-Protocol Label Switching) 등의 표준화가 완료되었고, IETF와 ITU-T가 공동으로 MPLS-TP(MPLS-Transport Profile) 기술에 대한 표준화를 진행하고 있다.
한편, ONF(Open Networking Foundation)는 오픈플로우(OpenFlow)를 기반으로 네트워크를 좀 더 손쉽게 프로그램 할 수 있는 소프트웨어 정의 네트워킹(SDN: Software Defined Networking, 이하, 'SDN'이라 약칭함) 기술을 정의하였다.
오픈플로우 기반 SDN 구조에서는 네트워크의 패킷 포워딩 평면(packet forwarding plane) 평면과 제어 평면(control plane)을 분리하고, 이들 두 기능 간의 통신을 위한 표준화된 프로토콜을 제공한다. 따라서, 오픈플로우 기술을 이용하면 외부의 중앙 집중화된 제어 장치에서 구동되는 소프트웨어를 이용하여 장비 제조업체와 무관하게 스위치 내의 패킷 경로를 결정할 수 있고, 기존보다 더 정밀하게 트래픽을 관리할 수 있다.
SDN 구조는 오픈플로우 스위치(OpenFlow Switch)와 컨트롤러(Controller)를 포함하고, 오픈플로우 스위치와 컨트롤러는 오픈플로우 프로토콜에 의해 상호 연결된다.
또한, 최근에는 OTWG(Optical Transport Working Group)을 통해 OAM 및 보호절체 기능이 정의된 패킷 및 광전달 네트워크에 SDN 기술을 확대 적용하고자 하는 연구가 진행되고 있다.
그러나, 상술한 바와 같은 전달 네트워크 기술의 발전에도 불구하고, 현재까지는 전달 네트워크를 구성하는 통신 장비가 OAM 기능을 지원하지 않거나, OAM 기능을 지원하는 경우에도 네트워크의 구성 환경에 따라 점대점(point-to-point) 경로의 장애를 인식할 수 없거나 인식에 지연이 발생하는 문제가 있다. 또한, 경로 장애를 인식하는 경우에도 복구에 많은 시간이 걸리는 문제가 있다.
본 발명의 목적은 OAM 기능의 제공 여부와 상관없이 점대점 경로 장애를 정확하고 신속하게 감지 및 복구할 수 있는 경로 장애 처리 방법을 제공하는 것이다.
본 발명에서 이루고자 하는 목적들은 상기한 목적으로 제한되지 않으며, 언급하지 않은 다른 목적들은 하기의 기재로부터 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 목적을 달성하기 위한 본 발명의 일 측면에 따른 장애 처리 방법은, 제1 네트워크의 장비들을 제어하는 제1 컨트롤러에서 수행되는 장애 처리 방법으로, 제2 네트워크의 장비와 연결된 제1 네트워크의 장비로부터 장애 발생 정보를 포함하는 장애 감지 메시지를 수신하는 단계와, 상기 장애 발생 정보에 기초하여 장애가 발생한 경로를 판단하고, 판단된 장애 경로와 연관된 제2 네트워크의 장비를 판단하는 단계 및 판단된 제2 네트워크의 장비 정보를 포함하는 장애 통보 메시지를 제2 컨트롤러에 전송하는 단계를 포함한다.
여기서, 상기 장애 발생 정보는 발생된 장애와 연관된 포트 정보 및 상기 제1 네트워크 내의 장애 발생 유무 정보 중 적어도 하나의 정보를 포함할 수 있다. 또한, 상기 장애 통보 메시지는 상기 제1 네트워크에서 장애의 복구 수행 여부를 지시하는 정보를 더 포함할 수 있다.
여기서, 상기 장애 경로와 연관된 제2 네트워크의 장비를 판단하는 단계에서는, 장애 발생 이전에 미리 구축된 상기 제1 네트워크의 장비들과 상기 제2 네트워크의 장비들의 경로 매핑 정보에 기초하여 상기 장애 경로와 연관된 제2 네트워크 장비를 판단할 수 있다.
여기서, 상기 장애 통보 메시지를 제2 컨트롤러에 전송하는 단계에서는, 상기 제2 컨트롤러가 다수인 경우, 장애 발생과 연관된 모든 제2 컨트롤러에 각각 유니캐스트 방식으로 상기 장애 통보 메시지를 각각 전송할 수 있다.
상기 장애 감지 메시지는 CDPI(Control Data Plane Interface) 메시지일 수 있고, 상기 장애 통보 메시지는 CVNI(Control Virtual Network Interface) 메시지일 수 있다.
또한, 본 발명의 목적을 달성하기 위한 본 발명의 다른 측면에 따른 장애 처리 방법은, 제1 네트워크의 장비들과 연결된 제2 네트워크의 장비들을 제어하는 제2 컨트롤러에서 수행되는 장애 처리 방법으로, 제1 컨트롤러로부터 장애 통보 메시지를 수신하는 단계와, 상기 장애 통보 메시지에 포함된 정보에 기초하여 장애와 연관된 제2 네트워크의 장비 정보를 확인하고, 장애 복구 수행 여부를 결정하는 단계 및 장애 복구를 수행하는 것으로 결정한 경우, 상기 장애와 연관된 제2 네트워크의 장비에 장애 복구를 위한 제어 메시지를 전송하는 단계를 포함한다.
여기서, 상기 장애 통보 메시지는 상기 제1 네트워크에서 장애의 복구 수행 여부를 지시하는 정보를 더 포함할 수 있다. 또한, 상기 장애 복구 수행 여부를 결정하는 단계에서는, 상기 장애의 복구 수행 여부를 지시하는 정보가 상기 제1 네트워크에서 장애 복구를 수행하지 않음을 지시하는 경우, 장애 복구를 수행하는 것으로 결정할 수 있다.
여기서, 상기 장애 복구 수행 여부를 결정하는 단계에서는, 상기 장애와 연관된 제2 네트워크의 장비에서 장애와 연관된 포트를 확인하고, 확인된 포트에 매핑된 네트워크를 확인할 수 있다. 또한, 상기 장애 복구를 위한 제어 메시지를 전송하는 단계에서는, 상기 확인된 포트 또는 상기 확인된 포트에 매핑된 네트워크 정보에 기초하여 상기 제2 네트워크의 장비에서 장애와 연관된 포트를 비활성화하거나, 상기 포트와 연관된 VLAN(Virtual Local Area Network)을 비활성화하기 위한 제어 메시지를 전송할 수 있다.
여기서, 상기 장애와 연관된 제2 네트워크의 장비는, 상기 제1 네트워크를 경유하여 제2 네트워크들간에 형성된 점대점 경로들 중 장애가 발생한 점대점 경로를 구성하는 적어도 두 개의 제2 네트워크 장비들인 것을 특징으로 하는 장애 처리 방법.
여기서, 상기 장애 복구를 위한 제어 메시지를 전송하는 단계에서는, 상기 장애와 연관된 제2 네트워크의 장비가 다수인 경우, 장애와 연관된 각 장비에 상응하는 제어 프로토콜을 이용하여 각 장비에 유니캐스트 방식으로 상기 제어 메시지를 전송할 수 있다.
또한, 본 발명의 목적을 달성하기 위한 본 발명의 또 다른 측면에 따른 장애 처리 방법은, 제1 네트워크의 장비 및 상기 제1 네트워크의 장비와 연결된 제2 네트워크의 장비를 제어하는 컨트롤러에서 수행되는 장애 처리 방법으로, 상기 제1 네트워크의 장비로부터 장애 발생 정보를 포함하는 장애 감지 메시지를 수신하는 단계와, 상기 장애 발생 정보에 기초하여 장애가 발생한 경로를 판단하고, 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득하는 단계 및 상기 장애 경로와 연관된 제2 네트워크의 장비에 장애 복구를 위한 제어 메시지를 전송하는 단계를 포함한다.
여기서, 상기 장애 발생 정보는 발생된 장애와 연관된 포트 정보 및 상기 제1 네트워크 내의 장애 발생 유무 정보 중 적어도 하나의 정보를 포함할 수 있다.
여기서, 상기 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득하는 단계에서는, 상기 장애 감지 메시지에 포함된 장애 포트 정보에 기초하여 장애가 발생한 경로를 판단하고, 장애 발생 이전에 미리 구축된 상기 제1 네트워크의 장비들과 상기 제2 네트워크의 장비들의 매핑 정보에 기초하여, 판단된 장애 경로와 연관된 제1 네트워크 장비에 대응되는 제2 네트워크의 장비 정보를 획득할 수 있다. 또한, 상기 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득하는 단계는, 상기 획득한 제2 네트워크 장비의 장애와 연관된 포트 및 상기 포트와 연관된 네트워크 매핑 정보를 획득할 수 있다.
여기서, 상기 제어 메시지를 전송하는 단계에서는, 상기 장애 경로와 연관된 제2 네트워크 장비에서 장애와 연관된 포트를 비활성화하거나, 상기 포트와 연관된 VLAN(Virtual Local Area Network)을 비활성화하기 위한 제어 메시지를 전송할 수 있다.
본 발명에 따른 통신 네트워크에서 경로 장애 처리 방법에 따르면, 서버 네트워크 또는 서버 네트워크와 클라이언트 네트워크가 연결된 경로에서 장애가 발생하는 경우, 컨트롤러가 장애 감지 메시지를 수신한 후 장애로부터 영향을 받는 장비에 장애 복구를 위한 제어 메시지를 전송한다.
따라서, 클라이언트 네트워크를 구성하는 통신 장비들이 장애 감지를 위한 기능을 지원하지 않는 경우에도 신속하게 장애를 감지할 수 있고, 감지된 장애를 신속하게 복구할 수 있다.
또한, 장애 발생 감지 및 장애 복구를 신속하게 수행함에 따라 장애가 발생된 클라이언트 네트워크 및/또는 서버 네트워크의 패킷 손실을 최소화 할 수 있고, 이를 통해 서비스 품질을 보장할 수 있다.
도 1은 전달 네트워크의 구조를 나타내는 개념도이다.
도 2 내지 도 4는 도 1에 도시한 바와 같은 네트워크 환경에서 발생할 수 있는 장애 유형 및 복구 방법을 설명하기 위한 개념도이다.
도 5는 라우팅 프로토콜 기능을 이용하여 장애를 감지하는 방법의 일 예를 나타내는 개념도이다.
도 6은 라우팅 프로토콜 기능을 이용하여 장애를 감지하는 방법의 다른 예를 나타내는 개념도이다.
도 7은 본 발명의 일 실시예에 따른 장애 처리 장치와 장애 처리 장치가 적용되는 네트워크 환경을 나타낸다.
도 8은 본 발명의 다른 실시예에 따른 장애 처리 장치와 장애 처리 장치가 적용되는 네트워크 환경을 나타낸다.
도 9는 본 발명의 일 실시예에 따른 장애 처리 과정을 나타내는 순서도이다.
도 10은 본 발명의 다른 실시예에 따른 장애 처리 과정을 나타내는 순서도이다.
도 11은 본 발명의 또 다른 실시예에 따른 장애 처리 과정을 나타내는 순서도이다.
도 12는 본 발명의 또 다른 실시예에 따른 장애 처리 과정을 나타내는 순서도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다.
그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제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은 전달 네트워크의 구조를 나타내는 개념도이다.
도 1을 참조하면, 전달 네트워크는 통신 사업자가 관리하는 다수의 클라이언트 네트워크와의 연동 관점에서 고려할 때, 서버(server)-클라이언트(client) 구조를 가진다.
도 1에서, 서버 네트워크 장비(PE: Provider Edge, 이하, 'PE'라 약칭함)(111, 112)가 위치하는 전달 네트워크(110)는 다수의 클라이언트 네트워크(120a, 120b)를 수용하는 서버 네트워크가 된다. 클라이언트 네트워크(120a, 120b)는 통신 사업자가 운용하는 서버 네트워크(110)의 고객이 되는 네트워크가 될 수도 있고, 동일 통신 사업자가 운용하는 다른 네트워크 영역(domain) 상에 존재하는 네트워크가 될 수도 있다.
서버 네트워크(110)에 위치하는 PE(111, 112)는 서버 네트워크(110)를 클라이언트 네트워크(120a, 120b)와 연결한다. 또한, 서버 네트워크(110) 내에 위치하는 PE(111, 112)들은 서로 연결되어 서버 네트워크(110) 내의 통신 경로를 형성한다.
클라이언트 네트워크(120a, 120b)에 각각 위치하는 클라이언트 네트워크 장비(CE: Client Equipment, 이하, 'CE'라 약칭함)(121, 122)는 클라이언트 네트워크(120a, 120b)를 서버 네트워크(110)의 PE(111, 112)와 연결한다. 또한, 클라이언트 네트워크(120a, 120b)내에 위치하는 CE(121, 122)는 클라이언트 네트워크 내의 다른 통신 장비들(미도시)과 연결되어 클라이언트 네트워크 내의 임의의 통신 장비에서 전송된 트래픽을 서버 네트워크(110)로 전달할 수 있고, 서버 네트워크(110)로부터 전송된 트래픽을 클라이언트 네트워크(120a, 120b)의 해당 통신 장비에 전달할 수 있다.
또한, 서버 네트워크(110)는 클라이언트 네트워크들(120a, 120b)간의 연결성을 제공하기 위해, 임의의 클라이언트 네트워크(120a)로부터 수신한 신호를 서버 네트워크(110) 내의 전달망 기술을 이용하여 해당 목적 클라이언트 네트워크(120b)로 전달한다. 예를 들어, PE1(111)이 CE1(121)으로부터 신호를 수신하면, PE1(111)은 수신한 신호를 PE2(112)에 전달하고, PE2(112)는 PE1(111)으로부터 수신한 신호를 CE2(122)로 전달함으로써, 서버 네트워크(110)는 클라이언트 네트워크들(120a, 120b)간의 연결성을 제공한다.
한편, CE1(121)과 CE2(122)는 클라이언트 계위상에서 이루어지는 OAM 설정을 통해 미리 정의된 주기적인 메시지를 송수신하고, 송수신 결과에 따라 종단간 장애를 감지할 수 있다. 여기서, 상기 주기적인 메시지는 연속성 확인(CC: Continuity Check, 이하, 'CC'라 약칭함) 메시지가 이용될 수 있다. 또한, 서버 계위상에서도 PE1(111)과 PE2(112) 사이에 주기적인 메시지(예를 들면, CC 메시지) 송수신 기능을 활성화 할 수 있다. 한편, CC 메시지 송수신 주기는 3.3 ms로 설정될 수 있고, CC 메시지를 수신하는 장비에서는 3회 연속 CC 메시지가 수신되지 않는 경우 장애로 판단할 수 있다.
도 2 내지 도 4는 도 1에 도시한 바와 같은 네트워크 환경에서 발생할 수 있는 장애 유형 및 복구 방법을 설명하기 위한 개념도이다.
먼저 도 2를 참조하면, PE1(211)과 PE2(212)가 위치한 서버 네트워크(210) 내에서 장애가 발생하는 경우, PE1(211)과 PE2(212)는 CC 메시지를 연속적으로 세 번 수신할 수 없게 되고, 이를 통해 현재의 경로(working path)에 장애가 발생하였음을 감지하게 된다. PE1(211)과 PE2(212)는 장애를 감지하면 CE1(221)으로부터 유입되는 트래픽을 동일 서버 네트워크 내에 설정된 대체 경로(protection path)로 절체하여 CE2(222)에 전달함으로써 50ms 이내에 장애를 복구할 수 있다.
또는, 도 3에 도시한 바와 같이 서버 네트워크(310)와 클라이언트 네트워크의 연결 구간인 PE2(312)와 CE2(322) 사이의 경로(또는 PE1(311)과 CE1(321) 사이의 경로)에 장애가 발생하는 경우, CE1(321)과 CE2(322)는 CC 메시지를 수신할 수 없게 되고, 이를 통해 장애를 감지할 수 있다. 이 경우, 도 3에 도시한 바와 같이 CE1(321)에서 장애를 감지하고 동일 서버 네트워크 내에서 멀티 호밍(multi-homing)을 통해 트래픽을 다른 경로로 우회함으로써 장애를 복구할 수 있다. 즉, PE2(312)와 CE2(322) 구간에서 장애가 발생한 경우, CE1(321)은 장애를 감지하고 PE1(311)으로 전송하던 트래픽을 PE3(313)로 전송함으로써, PE1(311)과 PE2(312) 사이의 작업 경로(working path A)로 전송하던 트래픽을 PE3(313)와 PE4(314) 사이의 작업 경로(working path B)를 통해 전송할 수 있다.
또는, 도 4에 도시한 바와 같이 제1 영역(domain A)의 서버 네트워크(410a)에 포함된 PE2(412)와 CE2(422) 사이에 장애가 발생한 경우, 지역적으로 떨어진 제2 영역(domain B)의 서버 네트워크(410b)로 트래픽을 우회시킬 수 있다. 즉, PE2(412)와 CE2(422) 사이에 장애가 발생하면, CE1(421)은 CC 메시지의 3회 연속 미수신을 통해 장애를 감지하고, 트래픽을 제2 영역 서버 네트워크(410b)의 PE3(413)와 연결된 CE3(423)에 전달함으로써 CE1(421)-CE3(423)-PE3(413)-PE4(414)-CE4(424)-CE2(422)의 경로를 통해 트래픽이 CE2(422)에 전달되도록 한다.
전달 네트워크를 운용하는 통신 사업자는 도 2 내지 도 4에 예시한 장애 발생의 경우에 네트워크의 환경 및 설계 기준 등에 따라 다양한 장애 복구 방법 중 임의의 방법을 선택할 수 있다.
그러나, 클라이언트 네트워크를 구성하는 통신 장비가 OAM 기능을 반드시 지원해야 하는 것은 아니므로 OAM 기능을 지원하지 않을 수도 있고, 클라이언트 네트워크의 통신 장비가 OAM 기능을 지원하는 경우에도 운영의 복잡도 또는 OAM 메시지로 인한 부하 증가 등의 이유로 OAM 기능이 비활성화된 상태에서 네트워크가 운영될 수 있다. 이와 같이 OAM 기능이 지원되지 않는 환경에서는 CE간 점대점 경로의 장애는 전달망에서 요구되는 50ms 이내에 복구되기 어렵다.
예를 들어, 도 2에 도시한 바와 같이 동일 서버 네트워크 내에 대체 경로(protection path)가 구성된 경우, 서버 네트워크 내에서 장애가 발생하면 PE 장비가 이를 감지하고 보호 절체 기능을 통해 대체 경로로 트래픽을 절체함으로써 50ms 이내에 경로 장애를 복구할 수 있다. 그러나, 도 4에 도시한 바와 같이 대체 경로를 다른 도메인 상의 서버 네트워크에 구성하고 CE 장비가 OAM을 통해 장애를 감지할 수 없는 경우에는, CE 장비가 50ms 이내에 장애를 감지하는 것도 어렵기 때문에, 클라이언트 네트워크의 트래픽을 신속하게 보호 절체하는 것은 실질적으로 불가능하다.
한편, 수십 내지 수초 내에 장애 감지가 어려운 상황에서 CE 사이의 링크 상황을 확인할 수 있는 라우팅 프로토콜 기능이 CE에 활성화되어 있다면, CE가 장애를 감지하는 것은 가능할 수 있다.
도 5는 라우팅 프로토콜 기능을 이용하여 장애를 감지하는 방법의 일 예를 나타내는 개념도이다.
도 5를 참조하면, 제1 영역(domain A)의 전달 네트워크(510a)에 포함된 PE1(511)과 PE2(512)가 각각 클라이언트 네트워크의 CE1(521)과 CE2(522)에 연결되고, 제2 영역(domain B)의 전달 네트워크(510b)에 포함된 PE3(513)와 PE4(514)가 각각 클라이언트 네트워크의 CE3(523)와 CE4(524)에 연결되며, CE1(521)과 CE3(523)가 연결되고, CE2(522)와 CE4(524)가 연결된 네트워크 환경에서, 클라이언트 네트워크의 CE1(521), CE2(522), CE3(523) 및 CE4(524)는 IGP(Interior Gateway Protocol) 라우팅 프로토콜을 지원하는 라우터인 것으로 가정한다.
도 5에 도시한 바와 같은 네트워크 환경에서, PE1(511)과 PE2(512) 사이의 경로에서 장애가 발생하면(S501), PE1(511)과 PE2(512)는 3회 연속 CC 메시지를 수신할 수 없게 된다(S502).
따라서, PE1(511)과 PE2(512)는 3회 연속 CC 메시지의 미수신을 통해 장애를 감지한다(S503).
PE1(511)과 PE2(512)에 각각 연결된 CE1(521)과 CE2(522)는 라우팅 프로토콜에 의해 인터페이스 간 주기적으로 헬로(Hello) 컨트롤 메시지를 전달하고, 전달 네트워크의 장애로 인하여 헬로 컨트롤 메시지는 상대 CE에 전달이 되지 않는다.
CE1(521)과 CE2(522)는 각각 헬로 컨트롤 메시지의 수신 타이머(Hello Timer)를 가동하고, 상기 수신 타이머가 만료될 때까지 헬로 컨트롤 메시지가 수신되지 않는 경우, 장애 발생을 인식하게 된다(S506).
즉, CE1(521)과 CE2(522)는 헬로 컨트롤 메시지의 전달이 실패하는 경우에만 종단간 경로 장애를 감지할 수 있고, 장애를 감지한 이후 갱신되는 라우팅 테이블을 통해 우회 경로로 트래픽을 전달할 수 있다. 여기서, OSPF(Open Shortest Path First) 프로토콜의 경우 기본적으로 30초를 기준으로 헬로 컨트롤 메시지의 유실을 판단하고, 헬로 컨트롤 메시지가 유실된 경우 해당 인터페이스의 장애를 판단하는 것이 일반적이기 때문에 최악의 경우 30초 이상 동안 장애를 감지하지 못할 수 있다.
고속 대용량 통신 경로에서 발생하는 장애의 감지에 지연이 있는 경우 다수 사용자의 트래픽에 대한 서비스 품질이 저하될 수 있기 때문에 장애를 신속하게 감지하는 것은 매우 중요하다.
한편, PE와 CE 경로에서 장애가 발생하면, 장애가 발생한 경로와 인접한 CE와 PE는 물리적 특성을 통해 통신 경로의 장애를 즉시 감지할 수 있으나, 장애 발생을 감지한 CE가 다른 CE로 장애 발생 사실을 전달할 수 있는 OAM 기능이 지원되지 않는 경우 50ms 이내에 트래픽을 대체 경로로 우회시키는 것은 불가능하다.
도 6은 라우팅 프로토콜 기능을 이용하여 장애를 감지하는 방법의 다른 예를 나타내는 개념도이다.
도 6을 참조하면, 전달 네트워크(610)에 포함된 PE1(611)과 PE2(612)는 각각 클라이언트 네트워크의 CE1(621)과 CE2(622)에 연결되고, 클라이언트 네트워크의 CE1(621) 및 CE2(622)는 IGP 라우팅 프로토콜을 지원하는 라우터인 것으로 가정한다.
도 6에 도시한 바와 같은 네트워크 환경에서, PE2(612)와 CE2(622) 사이의 구간에서 장애가 발생하면(S601), 장애와 인접한 PE2(612)와 CE2(622)는 장애를 바로 인식할 수 있다.
한편, CE2(622)가 CE1(621)으로 전송하는 헬로 컨트롤 메시지는 PE2(612)-CE2(622) 구간의 장애로 인하여 CE1(621)로 전송되지 않는다(S603).
CE1(621)은 헬로 타이머가 만료될 때까지 CE2(622)로부터 헬로 컨트롤 메시지를 수신하지 못하는 경우, 장애를 감지한다. 즉, CE1(621)은 CE2(622)로부터 전달되는 헬로 컨트롤 메시지를 수신하지 못한 것으로 판단한 후에야 비로소 장애를 감지할 수 있다. 이 때, CE1(621)으로 유입되는 트래픽은 CE1(621)이 장애를 감지하기 전까지는 장애가 발생한 경로로 계속 유입될 수 있다(S604).
상술한 바와 같이 서버 네트워크(또는 전달 네트워크)를 경유하여 트래픽을 전달하는 클라이언트 네트워크 장비가 OAM 기반으로 장애를 감지하지 못할 경우, 수십 초 이상의 장애 처리 지연으로 인하여 트래픽의 품질 저하가 발생한다. 클라이언트 네트워크 관점에서 반드시 OAM 기능이 제공되는 CE가 서버 네트워크와 연동되도록 구성되어야 하는 것은 아니다. 따라서, 통신 사업자 관점에서 OAM 기능이 제공되지 않는 클라이언트 네트워크 장비 간의 장애를 신속하게 감지할 수 있는 방법이 요구된다.
본 발명은 서버 네트워크(또는 전달 네트워크)를 경유하는 점대점(point-to-point) 경로에 대해, 중앙 집중형 컨트롤러를 이용하여 경로 장애를 감지하는 방법 및 장치를 제공함으로써, OAM 기능을 지원하지 않는 클라이언트 네트워크 장비들도 짧은 시간 내에(예를 들면, 50ms 내에) 장애를 감지할 수 있도록 할 수 있다.
도 7은 본 발명의 일 실시예에 따른 장애 처리 장치와 장애 처리 장치가 적용되는 네트워크 환경을 나타낸다.
도 7을 참조하면, 본 발명의 일 실시예에 따른 장애 처리 방법은, 서버 네트워크(710)와 클라이언트 네트워크(720a, 720b)가 연동하는 네트워크 환경에 적용될 수 있다.
서버 네트워크(710)는 전달 네트워크일 수 있고, 복수의 서버 네트워크 장비(711, 712)를 포함할 수 있다. 도 7에서는 설명의 편의를 위해 전달 네트워크(710)에 포함되는 서버 네트워크 장비(711, 712)가 PE인 것으로 예시하였으나, 이에 한정되는 것은 아니며 클라이언트 네트워크 장비(721, 722)와 연결되어 클라이언트 네트워크(720a, 720b)로부터 전달된 트래픽을 처리하는 장치는 어떤 장치라도 서버 네트워크 장비에 포함될 수 있다. 또한, 클라이언트 네트워크(720a, 720b) 역시 클라이언트 네트워크 장비(721, 722)를 포함할 수 있다. 도 7에서는 설명의 편의를 위해 클라이언트 네트워크(720a, 720b)에 각각 포함된 클라이언트 네트워크 장비(721, 722)가 CE인 것으로 예시하였으나, 이에 한정되는 것은 아니며 서버 네트워크(또는 전달 네트워크)(710)의 통신 장비와 연결되어 서버 네트워크(710)로 트래픽을 전달하는 기능을 수행하는 통신 장비는 어떤 장치라도 클라이언트 네트워크 장비에 포함될 수 있다.
도 7에서는 본 발명의 요지를 보다 명확하게 설명하기 위해 서버 네트워크(710)에 PE1(711)과 PE2(712)가 포함되고, 서로 다른 클라이언트 네트워크(720a, 720b)에 CE1(721)과 CE2(722)가 각각 포함되며, PE1(711)은 CE1(721)과 연결되고 PE2(712)는 CE2(722)에 연결된 것으로 예시하였으나, 서버 네트워크(710) 및 클라이언트 네트워크(720a, 720b)는 도 7에 예시된 통신 장비 이외에도 다수의 통신 장비들을 더 포함할 수 있음은 자명하다.
한편, 도 7에 예시한 바와 같이 본 발명에서는 장애 처리를 위해 제1 컨트롤러(730) 및 제2 컨트롤러(740)를 포함할 수 있다.
구체적으로, 제1 컨트롤러(730)는 서버 네트워크(710) 내에 위치하는 PE들(711, 712)과 연결되어, PE들(711, 712)의 동작을 제어할 수 있다. 또한, 제1 컨트롤러(730)는 표준화된 프로토콜을 통해 서버 네트워크(710)의 PE들(711, 712)을 제어할 수 있다. 예들 들어, 제1 컨트롤러(730)는 ONF의 OTWG에서 표준화된 CDPI(Control Data Plane Interface)를 통해 서버 네트워크(710)의 PE들(711, 712)을 제어할 수 있다.
제1 컨트롤러(730)는 SDN 표준에서 정의된 컨트롤러일 수도 있고, IETF의 I2RS(Interface to Routing System) 표준에서 정의된 클라이언트 또는 클라이언트의 기능을 수행할 있다.
제2 컨트롤러(740)는 각각의 클라이언트 네트워크(720a, 720b)에 위치하는 CE들(721, 722)과 연결될 수 있고, CE들(721, 722)로부터 분리된 제어 평면을 통합하여 중앙 집중적으로 CE들(721, 722)을 제어할 수 있다. 여기서, 제2 컨트롤러(740)는 예를 들어, SDN 표준에서 정의된 컨트롤러일 수도 있고, IETF의 I2RS 표준에서 정의된 클라이언트 또는 클라이언트의 기능을 수행할 있다. 또한, 제2 컨트롤러(740)는 SDN의 오픈플로우 프로토콜, IETF의 I2RS 또는 ForCES(Forwarding and Control Element Separation) 등의 표준화된 프로토콜을 통해 CE들(721, 722)을 제어할 수 있다.
한편, 제2 컨트롤러(740)는 표준화된 프로토콜 예들 들면, CVNI(Control Virtual Network Interface)를 통해 제1 컨트롤러(730)와 연동할 수 있다. 즉, 제2 컨트롤러(740)는 미리 정의된 CVNI 메시지를 통해 제1 컨트롤러(730)와 장애 정보, 장애 처리, 경로 설정 등의 정보를 주고받을 수 있다.
제2 컨트롤러(740)는 제1 컨트롤러(730)에 점대점 연결에 필요한 서버 네트워크(710) 내의 경로에 대한 생성 또는 해제를 요청할 수 있다.
한편, 제1 컨트롤러(730)는 장애 관리 및/또는 성능 측정 등에 따른 정보(예를 들면, 알람 정보 등)를 표준화된 메시지를 통해 제2 컨트롤러(740)에 통보할 수 있다.
제1 컨트롤러(730) 및 제2 컨트롤러(740)의 장애 처리와 관련된 기능들은 도 9 및 도 11을 참조하여 보다 상세하게 설명한다.
한편, 도 7에 도시한 제1 컨트롤러(730)와 제2 컨트롤러(740)는 하나의 컨트롤러로 통합된 형태로 운용될 수도 있다.
도 8은 본 발명의 다른 실시예에 따른 장애 처리 장치와 장애 처리 장치가 적용되는 네트워크 환경을 나타낸다.
도 8에 예시된 네트워크 환경에서 서버 네트워크(810)의 구성과 클라이언트 네트워크(820a, 820b)의 구성은 도 7에 도시한 해당 네트워크와 동일하나, 도 8에서는 도 7의 제1 컨트롤러(730)와 제2 컨트롤러(740)가 하나의 통합 컨트롤러(850)로 구성된다는 점에서 차이가 있다.
통합 컨트롤러(850)는 각각의 클라이언트 네트워크(820a, 820b)에 위치하는 CE들(821, 822) 및 서버 네트워크(810)에 위치하는 PE들(811, 812)과 연결될 수 있고, CE들(821, 822)로부터 분리된 제어 평면을 통합하여 중앙 집중적으로 CE들(821, 822)을 제어할 수 있다. 통합 컨트롤러(850)는 예를 들어, SDN 표준에서 정의된 컨트롤러일 수도 있고, IETF의 I2RS 표준에서 정의된 클라이언트 또는 클라이언트의 기능을 수행할 있다. 또한, 통합 컨트롤러(850)는 SDN의 오픈플로우 프로토콜 또는 I2RS 등의 표준화된 프로토콜을 통해 CE들(821, 822)을 제어할 수 있다.
또한, 통합 컨트롤러(850)는 CDPI 등과 같은 표준화된 프로토콜을 통해 서버 네트워크(810)의 PE들(811, 812)을 제어할 수 있다. 예들 들어, 통합 컨트롤러(850)는 ONF의 OTWG에서 표준화된 CDPI를 통해 서버 네트워크(810)의 PE들(811, 812)을 제어할 수 있다.
통합 컨트롤러(850)는 점대점 연결에 필요한 서버 네트워크(810) 내의 경로에 대한 생성이나 해제를 위한 제어를 수행할 수 있고, 장애 관리 및/또는 성능 측정과 이에 따른 처리를 수행할 수 있다.
통합 컨트롤러(850)의 장애 처리와 관련된 기능들은 도 10 및 도 12를 참조하여 보다 상세하게 설명한다.
이하에서는 도 9 내지 도 12를 참조하여 본 발명의 실시예들에 따른 장애 처리 방법을 보다 구체적으로 설명한다.
도 9는 본 발명의 일 실시예에 따른 장애 처리 과정을 나타내는 순서도로, 도 7에 예시한 바와 같이 제1 컨트롤러(730) 및 제2 컨트롤러(740)를 포함하는 네트워크 환경에서 수행되는 장애 처리 과정을 나타낸다.
도 9에서는 서버 네트워크에 위치하는 PE1(711)과 PE2(712) 사이의 구간에서 장애가 발생한 경우, 제1 컨트롤러(730) 및 제2 컨트롤러(740)를 이용하여 OAM 기능을 제공하지 않는 클라이언트 네트워크 장비(CE1(721) 및 CE2(722))에서 장애를 감지하도록 하는 장애 처리 과정을 예시하였다.
도 9를 참조하면, 먼저 서버 네트워크의 종단에 위치한 PE1(711)과 PE2(712) 사이에서 장애가 발생하는 경우, PE1(711)과 PE2(712)는 OAM 메시지인 CC 메시지를 수신할 수 없게 된다(S901).
따라서, PE1(711)과 PE2(712)는 각각 CC 메시지의 미수신을 통해 장애 발생을 감지한다(S902).
장애를 감지한 PE1(711) 및 PE2(712)는 미리 정의된 표준화된 장애 감지 메시지(예를 들면, CDPI 메시지)를 통해 제1 컨트롤러(730)에 장애 발생 사실을 통보한다(S903). 여기서, PE1(711) 및 PE2(712)가 전송하는 장애 감지 메시지 내에는 서버 네트워크 내에서 장애가 발생한 포트에 대한 정보와, 서버 네트워크 내의 장애 발생 여부를 지시하는 정보가 포함될 수 있다. 상기 장애 감지 메시지는 장애를 감지한 이후에 메시지 유실을 방지하기 위해 미리 설정된 시간 간격(예를 들면, 수 ms) 및 회수에 따라 반복적으로 전송될 수 있다. 한편, PE1(711)과 PE2(712)가 장애를 감지한 경우 PE1(711) 및 PE2(712)가 모두 장애 감지 메시지를 제1 컨트롤러(730)에 전송할 수도 있고, PE1(711)과 PE2(712) 중 어느 하나만 제1 컨트롤러(730)에 장애 감지 메시지를 전송할 수도 있다. 도 9에서는 PE1(711)과 PE2(712)가 모두 장애를 감지하고 제1 컨트롤러(730)에 장애 감지 메시지를 전송하는 것으로 예시하였다.
제1 컨트롤러(730)는 PE2(712)과 PE2(712)로부터 전송된 장애 감지 메시지를 수신하면, 장애 감지 메시지에 포함된 장애 정보(예를 들면, 장애 포트 정보)에 기초하여 장애가 발생한 경로를 판단한 후, 장애 통보 메시지를 통해 제2 컨트롤러(740)에게 장애 정보를 통보한다(S904). 여기서, 상기 장애 통보 메시지는 CVNI 메시지와 같이 표준화된 프로토콜 메시지로 구성될 수 있다. 또한, 장애 통보 메시지에는 서버 네트워크의 장애 경로와 연관된 모든 CE의 정보가 포함될 수 있다. 제1 컨트롤러(730)는 장애가 발생하기 이전에 최초로 경로를 설정하는 과정에서 PE와 CE간 경로의 매핑(예를 들면, PE1(711)-CE1(721), PE2(712)-CE2(722)) 정보를 저장함으로써, 장애가 발생한 경우 장애가 발생된 경로에 해당하는 PE와 CE간의 매핑 정보를 알 수 있다. 또한, 다수의 제2 컨트롤러가 제1 컨트롤러(730)와 연결되어 있는 경우, 제1 컨트롤러(730)는 서버 네트워크의 장애과 연관된 모든 제2 컨트롤러에게 장애 통보 메시지를 유니캐스트(unicast) 방식으로 전달할 수 있다.
도 9에서는 제1 컨트롤러(730)가 장애 통보 메시지에 서버 네트워크의 장애 경로와 연관된 CE 정보로 CE1(721), CE2(722) 정보를 포함시켜 제2 컨트롤러(740)에 전송하는 것으로 예시하였다.
또한, 장애 통보 메시지에는 서버 네트워크에서 장애 복구 수행 여부를 지시하는 정보를 포함할 수 있다. 상기 장애 복구 수행 여부를 지시하는 정보는 미리 설정된 비트 크기를 가지는 장애 복구 수행 지시자로 구성될 수 있다.
제2 컨트롤러(740)는 제1 컨트롤러(730)로부터 제공된 장애 통보 메시지를 수신하면, 수신한 장애 통보 메시지로부터 장애가 발생한 CE의 노드 정보를 확인한다.
또한, 제2 컨트롤러(740)는 수신한 장애 통보 메시지에 포함된 정보로부터 서버 네트워크의 장애 복구 수행 여부 정보를 확인한다. 여기서, 제2 컨트롤러(740)는 서버 네트워크가 장애를 복구하는 것으로 확인되는 경우, 장애를 인지하였음에도 불구하고 장애 복구 처리에 개입하지 않을 수 있다.
또는, 제2 컨트롤러(740)는 수신한 장애 통보 메시지를 확인하여 서버 네트워크가 장애 복구를 수행하지 않는 것으로 확인되면, 장애 복구를 수행한다. 도 9에서는 설명의 편의를 위하여 제1 컨트롤러(730)가 장애 통보 메시지에 장애 복구를 수행하지 않음을 지시하는 정보를 포함시키고, 이에 따라 제2 컨트롤러(740)가 장애 복구를 수행하는 것으로 예시하였다.
우선, 제2 컨트롤러(740)는 제1 컨트롤러(730)로부터 수신한 장애 통보 메시지로부터 장애와 연관된 CE 정보를 확인하고, 확인한 CE에 대해 자체적으로 저장하고 있는 서버 네트워크의 PE와 연결되는 CE의 포트 및 해당 포트의 VLAN(Virtual Local Area Network) 매핑 정보를 검색한다.
이후, 제2 컨트롤러(740)는 클라이언트 네트워크의 해당 CE를 제어하는 인터페이스 규격에 따라 검색된 해당 CE의 장애 포트 전체를 물리적으로 비활성화 시키거나, 장애 포트 내에서 해당 장애가 발생된 구간에 연결된 특정 VLAN에 대해서만 비활성화(shutdown) 시키기 위한 제어 메시지를 해당 CE(즉, CE1(721) 및 CE2(722))에 전송한다(S905). 예를 들면, CE가 일반 라우터 장비일 경우 제2 컨트롤러(740)는 SNMP(Simple Network Management Protocol)을 이용하여 물리적인 포트 또는 해당 포트의 일부 VLAN을 비활성화 시킬 수 있다. 또는, CE가 오픈플로우 기반 장비일 경우 제2 컨트롤러(740)는 오픈플로우 제어 메시지를 통해 포트 제어를 수행할 수 있다. 또는, 해당 CE가 I2RS 또는 ForCES 기반의 장비를 경우, 제2 컨트롤러(740)는 해당 표준 프로토콜을 통해서 장애 발생과 연관된 CE를 제어할 수 있다. 한편, 클라이언트 네트워크 내의 장애와 연관된 모든 노드들(또는 CE들)은 포트 정보 및/또는 VLAN 정보가 각각 다를 수 있기 때문에 제2 컨트롤러(740)는 유니캐스트 방식으로 해당 노드에게 제어 메시지를 전달한다. 예를 들어, 도 9에서 제2 컨트롤러(740)는 CE1(721) 및 CE2(722)에게 각각의 해당 포트 및 VLAN을 비활성화 하기 위한 제어 메시지를 유니캐스트 방식으로 각각 전달한다.
이후, 제2 컨트롤러(740)로부터 제어 메시지를 수신한 CE들(CE1(721) 및 CE2(722))은 수신한 제어 메시지에 따라 동작을 수행함으로써 우회 경로를 통해 트래픽을 전달할 수 있게 된다.
도 10은 본 발명의 다른 실시예에 따른 장애 처리 과정을 나타내는 순서도로, 도 8에 예시한 바와 같이 통합 컨트롤러(850)를 포함하는 네트워크 환경에서 수행되는 장애 처리 과정을 나타낸다.
도 10에서는 서버 네트워크에 위치하는 PE1(811)과 PE2(812) 사이의 구간에서 장애가 발생한 경우, 통합 컨트롤러(850)를 이용하여 OAM 기능을 제공하지 않는 클라이언트 네트워크 장비(CE1(821) 및 CE2(822))에서 장애를 감지하도록 하는 장애 처리 과정을 예시하였다.
도 10을 참조하면, 먼저 서버 네트워크의 종단에 위치한 PE1(811)과 PE2(812) 사이에서 장애가 발생하는 경우, PE1(811)과 PE2(812)는 OAM 메시지인 CC 메시지를 수신할 수 없게 되고(S1001), 이에 따라 PE1(811)과 PE2(812)는 장애 발생을 감지한다(S1002).
장애를 감지한 PE1(811) 및 PE2(812)는 미리 정의된 표준화된 메시지(예를 들면, CDPI 메시지)를 통해 통합 컨트롤러(850)에 장애 발생 사실을 통보한다(S1003). 여기서, PE1(811) 및 PE2(812)가 전송하는 장애 감지 메시지 내에는 서버 네트워크 내에서 장애가 발생한 포트에 대한 정보와, 서버 네트워크 내에서 장애가 발생하였음을 지시하는 정보가 포함될 수 있다. 상기 장애 감지 메시지는 미리 설정된 시간 간격 및 회수에 따라 반복적으로 전송될 수 있다.
통합 컨트롤러(850)는 PE2(812)과 PE2(812)로부터 전송된 장애 감지 메시지를 수신하면, 장애 감지 메시지에 포함된 장애 정보(예를 들면, 장애 포트 정보)에 기초하여 장애가 발생한 경로를 판단한 후, 장애가 발생된 경로에 해당하는 PE에 대응되는 CE 정보를 획득한다. 여기서, 통합 컨트롤러(850)는 장애가 발생하기 이전에 최초로 경로를 설정하는 과정에서 PE와 CE간 경로의 매핑(즉, PE1(811)-CE1(821), PE2(812)-CE2(822)) 정보를 저장함으로써, 장애가 발생한 경우 장애가 발생된 경로에 해당하는 PE와 CE간의 매핑 정보를 알 수 있다.
또한, 통합 컨트롤러(850)는 확인된 CE에 대해 장애가 발생한 PE와 연관된 CE의 포트 및 해당 포트의 VLAN 매핑 정보를 획득한다. 여기서, 각 CE의 포트 정보 및 각 포트의 VLAN 매핑 정보는 경로 설정과정에서 통합 컨트롤러(850)에 미리 저장될 수 있다.
이후, 통합 컨트롤러(850)는 획득한 정보에 기초하여 클라이언트 네트워크의 CE를 제어하는 인터페이스 규격에 따라 검색된 해당 CE의 장애 포트 전체를 물리적으로 비활성화 시키거나, 장애 포트 내에서 해당 장애가 발생된 구간에 연결된 특정 VLAN에 대해서만 비활성화(shutdown) 시키기 위한 제어 메시지를 해당 CE(CE1(821) 및 CE2(822))에 전송한다(S1004). 여기서, 클라이언트 네트워크 내의 장애와 연관된 모든 노드들(또는 CE들)은 포트 정보 및/또는 VLAN 정보가 각각 다를 수 있기 때문에 통합 컨트롤러(850)는 유니캐스트 방식으로 해당 노드에게 제어 메시지를 전달할 수 있다.
이후, 통합 컨트롤러(850)로부터 제어 메시지를 수신한 CE들(CE1(821) 및 CE2(822))은 수신한 제어 메시지에 따라 동작을 수행함으로써 우회 경로를 통해 트래픽을 전달할 수 있게 된다.
도 11은 본 발명의 또 다른 실시예에 따른 장애 처리 과정을 나타내는 순서도로, 도 7에 예시한 바와 같이 제1 컨트롤러(730) 및 제2 컨트롤러(740)를 포함하는 네트워크 환경에서 수행되는 장애 처리 과정을 나타낸다.
도 11에서는 서버 네트워크와 클라이언트 네트워크의 연결 구간(PE2(712)-CE2(722))에서 장애가 발생한 경우, 제1 컨트롤러(730) 및 제2 컨트롤러(740)를 이용하여 OAM 기능을 제공하지 않는 클라이언트 네트워크 장비(CE1(721) 및 CE2(722))에서 장애를 감지하도록 하는 장애 처리 과정을 예시하였다.
도 11을 참조하면, 먼저 서버 네트워크의 종단에 위치한 PE2(712)와 클라이언트 네트워크의 CE2(722) 사이에서 장애가 발생하는 경우, 발생된 장애와 직접적인 관련이 있는 PE2(712)와 CE2(722)는 물리적인 인터페이스의 신호 손실 등을 통해 장애를 감지할 수 있다(S1101).
장애를 감지한 PE2(712)는 장애 감지 메시지를 제1 컨트롤러(730)에 전송한다(S1102). 여기서, PE2(712)는 CDPI 메시지와 같이 미리 정의된 표준화된 메시지를 통해 제1 컨트롤러(730)에 장애 발생 사실을 통보할 수 있다. 또한, 장애 감지 메시지에는 장애가 발생하거나 장애와 연관된 포트에 대한 정보와, 서버 네트워크 내부의 장애 발생 유무 정보를 포함할 수 있다. 도 11에서는 서버 네트워크의 외부에서 장애가 발생된 것으로 예시하였으므로, PE2(712)는 서버 네트워크의 외부에서 장애가 발생하였음을 지시하는 정보를 장애 감지 메시지에 포함시켜 제1 컨트롤러(730)에 전송할 수 있다.
한편, 서버 네트워크 고유의 OAM 기능을 통해 서버 네트워크의 다른 종단에 위치한 PE1(711)도 서버 네트워크 외부에서 장애가 발생하였음을 인지할 수 있다. 예를 들어, PE2(712)는 표준화된 OAM 메시지(예를 들면, ITU-T의 Client Signal Failure 메시지)를 통해 PE2(712)와 CE2(722) 구간에서 장애가 발생하였음을 PE1(711)에 알려줄 수 있고, PE1(711)은 이를 통해 장애 발생을 인지할 수 있다. 이 경우, PE1(711)도 장애 감지 메시지를 제1 컨트롤러(730)에 전송할 수 있다.
제1 컨트롤러(730)는 PE2(712)로부터 장애 감지 메시지를 수신하면, 수신한 장애 감지 메시지를 확인하여 서버 네트워크의 외부 즉, 서버 네트워크와 클라이언트 네트워크의 연결 구간에서 장애가 발생되었음을 인지한다.
이후, 제1 컨트롤러(730)는 수신한 장애 감지 메시지에 포함된 장애 포트 정보와 연관된 서버 네트워크의 장애 경로 정보 및 장애 경로와 맵핑된 클라이언트 네트워크의 장비를 검색한다. 여기서, 제1 컨트롤러(730)는 장애가 발생하기 이전에 경로를 설정하는 과정에서 PE와 CE간 경로의 매핑(즉, PE1(711)-CE1(721), PE2(712)-CE2(722)) 정보를 저장함으로써, 장애가 발생한 경우 장애가 발생된 경로에 해당하는 PE와 CE간의 매핑 정보를 알 수 있다.
제1 컨트롤러(730)는 장애가 발생된 클라이언트 네트워크 장비 정보(즉, CE2(722)) 및 서버 네트워크의 장애 복구 수행 여부를 지시하는 정보를 포함하는 장애 통보 메시지(예를 들면, CVNI 메시지)를 제2 컨트롤러(740)에 전송한다(S1103). 도 11에서는 제1 컨트롤러(730)가 서버 네트워크에서 장애 복구를 수행하지 않음을 지시하는 정보를 장애 통보 메시지에 포함시켜 제2 컨트롤러(740)로 전송하는 것으로 가정한다. 한편, 다수의 제2 컨트롤러(740)가 제1 컨트롤러(730)와 연결되어 있는 경우, 제1 컨트롤러(730)는 장애와 연관된 모든 제2 컨트롤러(740)에 유니캐스트 방식으로 각각 장애 통보 메시지를 전달할 수 있다.
제2 컨트롤러(740)는 제1 컨트롤러(730)로부터 장애 통보 메시지를 수신하면, 장애 통보 메시지로부터 장애가 발생된 CE 정보 및 서버 네트워크의 장애 복구 수행 여부를 확인한다.
그리고, 제2 컨트롤러(740)는 자체적으로 저장하고 있는 정보로부터 서버 네트워크의 PE와 연결되는 해당 CE 노드의 포트 및 해당 포트의 VLAN(Virtual Local Area Network) 매핑 정보를 검색한다.
이후, 제2 컨트롤러(740)는 클라이언트 네트워크의 CE를 제어하는 인터페이스 규격에 따라 검색된 해당 CE의 장애 포트 전체를 물리적으로 비활성화 시키거나, 장애 포트 내에서 해당 장애가 발생된 구간에 연결된 특정 VLAN에 대해서만 비활성화(shutdown) 시키기 위한 제어 메시지를 해당 CE(CE1(721) 및 CE2(722))에 전송한다(S1104). 여기서, 제2 컨트롤러(740)는 장애와 연관된 CE에 따라 SNMP, 오픈플로우, I2RS 또는 ForCES 등의 프로토콜 중 해당 프로토콜을 이용하여 해당 CE를 제어할 수 있다.
이후, 제2 컨트롤러(740)로부터 제어 메시지를 수신한 CE들(CE1(721) 및 CE2(722))는 수신한 제어 메시지에 따라 동작을 수행함으로써 우회 경로를 통해 트래픽을 전달할 수 있게 된다.
도 12는 본 발명의 또 다른 실시예에 따른 장애 처리 과정을 나타내는 순서도로, 도 8에 예시한 바와 같이 통합 컨트롤러(850)를 포함하는 네트워크 환경에서 수행되는 장애 처리 과정을 나타낸다.
도 12에서는 서버 네트워크와 클라이언트 네트워크의 연결 구간(PE2(812)-CE2(822))에서 장애가 발생한 경우, 통합 컨트롤러(850)를 이용하여 OAM 기능을 제공하지 않는 클라이언트 네트워크 장비(CE1(821) 및 CE2(822))에서 장애를 감지하도록 하는 장애 처리 과정을 예시하였다.
도 12를 참조하면, 먼저 서버 네트워크의 종단에 위치한 PE2(812)와 클라이언트 네트워크의 CE2(822) 사이에서 장애가 발생하는 경우, 발생된 장애와 직접적인 관련이 있는 PE2(812)와 CE2(822)는 물리적인 인터페이스의 신호 손실 등을 통해 장애를 감지할 수 있다(S1201).
장애를 감지한 PE2(812)는 장애 감지 메시지를 통합 컨트롤러(850)에 전송한다(S1202). 여기서, PE2(812)는 CDPI 메시지와 같이 미리 정의된 표준화된 메시지를 통해 통합 컨트롤러(850)에 장애 발생 사실을 통보할 수 있다. 또한, 장애 감지 메시지에는 장애가 발생하거나 장애와 연관된 포트에 대한 정보와, 서버 네트워크 내부의 장애 발생 여부 정보를 포함할 수 있다. 도 12에서는 서버 네트워크의 외부에서 장애가 발생된 것으로 예시하였으므로, PE2(812)는 서버 네트워크의 외부에서 장애가 발생하였음을 지시하는 정보를 장애 감지 메시지에 포함시켜 통합 컨트롤러(850)에 전송할 수 있다.
한편, PE1(811)은 서버 네트워크 고유의 OAM 기능을 통해 PE2(812)로부터 서버 네트워크 외부에서 장애가 발생하였음을 통보 받고 장애가 발생하였음을 인지할 수 있다. 이 경우, PE1(811)도 장애 감지 메시지를 통합 컨트롤러(850)에 전송할 수 있다.
통합 컨트롤러(850)는 PE2(812)로부터 장애 감지 메시지를 수신하면, 수신한 장애 감지 메시지를 확인하여 서버 네트워크의 외부에서 장애가 발생되었음을 인지하고, 장애 포트와 연관된 서버 네트워크의 장애 경로 정보 및 장애 경로와 맵핑된 클라이언트 네트워크의 장애 장비를 검색한다. 여기서, 통합 컨트롤러(850)는 장애가 발생하기 이전에 경로를 설정하는 과정에서 PE와 CE간 경로의 매핑(즉, PE1(811)-CE1(821), PE2(812)-CE2(822)) 정보를 저장함으로써, 장애가 발생한 경우 장애가 발생된 경로에 해당하는 PE와 CE간의 매핑 정보를 알 수 있다.
또한, 통합 컨트롤러(850)는 미리 저장된 정보로부터 장애 발생과 연관된 CE 노드의 포트 및 해당 포트의 VLAN 매핑 정보를 획득한다.
이후, 통합 컨트롤러(850)는 클라이언트 네트워크의 CE를 제어하는 인터페이스 규격에 따라 검색된 해당 CE의 장애 포트 전체를 물리적으로 비활성화 시키거나, 장애 포트 내에서 해당 장애가 발생된 구간에 연결된 특정 VLAN에 대해서만 비활성화(shutdown) 시키기 위한 제어 메시지를 해당 CE(CE1(821) 및 CE2(822))에 전송한다(S1203).
여기서, 통합 컨트롤러(850)는 장애와 연관된 CE에 따라 SNMP, 오픈플로우, I2RS 또는 ForCES 등의 프로토콜 중 해당 프로토콜을 이용하여 해당 CE를 제어할 수 있다.
통합 컨트롤러(850)로부터 제어 메시지를 수신한 CE들(CE1(821) 및 CE2(822))은 수신한 제어 메시지에 따라 동작을 수행함으로써 우회 경로를 통해 트래픽을 전달할 수 있게 된다.
이상 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.
110 : 전달 네트워크 111 : PE1
112 : PE2 120a, 120b : 클라이언트 네트워크
121 : CE1 122 : CE2
210 : 서버 네트워크 211 : PE1
212 : PE2 221 : CE1
222 : CE2
310 : 서버 네트워크 311 : PE1
312 : PE2 313 : PE3
314 : PE4 321 : CE1
322 : CE2
410a : 서버 네트워크(제1 영역) 410b : 서버 네트워크(제2 영역)
411 : PE1 412 : PE2
413 : PE3 414 : PE4
421 : CE1 422 : CE2
423 : CE3 424 : CE4
510a : 전달 네트워크(제1 영역) 510b : 전달 네트워크(제2 영역)
511 : PE1 512 : PE2
513 : PE3 514 : PE4
521 : CE1 522 : CE2
523 : CE3 524 : CE4
610 : 전달 네트워크 611 : PE1
612 : PE2 621 : CE1
622 : CE2
710 : 서버 네트워크 711 : PE1
712 : PE2 720a, 720b : 클라이언트 네트워크
721 : CE1 722 : CE2
730 : 제1 컨트롤러 740 : 제2 컨트롤러
810 : 서버 네트워크 811 : PE1
812 : PE2 820a, 820b : 클라이언트 네트워크
821 : CE1 822 : CE2
850 : 통합 컨트롤러

Claims (19)

  1. 제1 네트워크의 장비들을 제어하는 제1 컨트롤러에서 수행되는 장애 처리 방법으로,
    제2 네트워크의 장비와 연결된 제1 네트워크의 장비로부터 장애 발생 정보를 포함하는 장애 감지 메시지를 수신하는 단계;
    상기 장애 발생 정보에 기초하여 장애가 발생한 경로를 판단하고, 판단된 장애 경로와 연관된 제2 네트워크의 장비를 판단하는 단계; 및
    판단된 제2 네트워크의 장비 정보를 포함하는 장애 통보 메시지를 제2 컨트롤러에 전송하는 단계를 포함하고,
    상기 장애 경로와 연관된 제2 네트워크의 장비를 판단하는 단계에서는, 장애 발생 이전에 미리 구축된 상기 제1 네트워크의 장비들과 상기 제2 네트워크의 장비들의 경로 매핑 정보에 기초하여 상기 장애 경로와 연관된 제2 네트워크 장비를 판단하는 것을 특징으로 하는 장애 처리 방법.
  2. 청구항 1에서,
    상기 장애 발생 정보는 발생된 장애와 연관된 포트 정보 및 상기 제1 네트워크 내의 장애 발생 유무 정보 중 적어도 하나의 정보를 포함하는 것을 특징으로 하는 장애 처리 방법.
  3. 청구항 1에서,
    상기 장애 통보 메시지는 상기 제1 네트워크에서 장애의 복구 수행 여부를 지시하는 정보를 더 포함하는 것을 특징으로 하는 장애 처리 방법.
  4. 삭제
  5. 청구항 1에서,
    상기 장애 통보 메시지를 제2 컨트롤러에 전송하는 단계는
    상기 제2 컨트롤러가 다수인 경우, 장애 발생과 연관된 모든 제2 컨트롤러에 각각 유니캐스트 방식으로 상기 장애 통보 메시지를 각각 전송하는 것을 특징으로 하는 장애 처리 방법.
  6. 청구항 1에서,
    상기 장애 감지 메시지는 CDPI(Control Data Plane Interface) 메시지인 것을 특징으로 하는 장애 처리 방법.
  7. 청구항 1에서,
    상기 장애 통보 메시지는 CVNI(Control Virtual Network Interface) 메시지인 것을 특징으로 하는 장애 처리 방법.
  8. 제1 네트워크의 장비들과 연결된 제2 네트워크의 장비들을 제어하는 제2 컨트롤러에서 수행되는 장애 처리 방법으로,
    제1 컨트롤러로부터 장애 통보 메시지를 수신하는 단계;
    상기 장애 통보 메시지에 포함된 정보에 기초하여 장애와 연관된 제2 네트워크의 장비 정보를 확인하고, 장애 복구 수행 여부를 결정하는 단계; 및
    장애 복구를 수행하는 것으로 결정한 경우, 상기 장애와 연관된 제2 네트워크의 장비에 장애 복구를 위한 제어 메시지를 전송하는 단계를 포함하고,
    상기 장애와 연관된 제2 네트워크의 장비는, 상기 제1 네트워크를 경유하여 제2 네트워크들간에 형성된 점대점 경로들 중 장애가 발생한 점대점 경로를 구성하는 적어도 두 개의 제2 네트워크 장비들인 것을 특징으로 하는 장애 처리 방법.
  9. 청구항 8에서,
    상기 장애 통보 메시지는 상기 제1 네트워크에서 장애의 복구 수행 여부를 지시하는 정보를 더 포함하는 것을 특징으로 하는 장애 처리 방법.
  10. 청구항 9에서,
    상기 장애 복구 수행 여부를 결정하는 단계에서는, 상기 장애의 복구 수행 여부를 지시하는 정보가 상기 제1 네트워크에서 장애 복구를 수행하지 않음을 지시하는 경우, 장애 복구를 수행하는 것으로 결정하는 것을 특징으로 하는 장애 처리 방법.
  11. 청구항 8에서,
    상기 장애 복구 수행 여부를 결정하는 단계에서는, 상기 장애와 연관된 제2 네트워크의 장비에서 장애와 연관된 포트를 확인하고, 확인된 포트에 매핑된 네트워크를 확인하는 것을 특징으로 하는 장애 처리 방법.
  12. 청구항 11에서,
    상기 장애 복구를 위한 제어 메시지를 전송하는 단계에서는, 상기 확인된 포트 또는 상기 확인된 포트에 매핑된 네트워크 정보에 기초하여 상기 제2 네트워크의 장비에서 장애와 연관된 포트를 비활성화하거나, 상기 포트와 연관된 VLAN(Virtual Local Area Network)을 비활성화하기 위한 제어 메시지를 전송하는 것을 특징으로 하는 장애 처리 방법.
  13. 삭제
  14. 청구항 8에서,
    상기 장애 복구를 위한 제어 메시지를 전송하는 단계에서는, 상기 장애와 연관된 제2 네트워크의 장비가 다수인 경우, 장애와 연관된 각 장비에 상응하는 제어 프로토콜을 이용하여 각 장비에 유니캐스트 방식으로 상기 제어 메시지를 전송하는 것을 특징으로 하는 장애 처리 방법.
  15. 제1 네트워크의 장비 및 상기 제1 네트워크의 장비와 연결된 제2 네트워크의 장비를 제어하는 컨트롤러에서 수행되는 장애 처리 방법으로,
    상기 제1 네트워크의 장비로부터 장애 발생 정보를 포함하는 장애 감지 메시지를 수신하는 단계;
    상기 장애 발생 정보에 기초하여 장애가 발생한 경로를 판단하고, 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득하는 단계; 및
    상기 장애 경로와 연관된 제2 네트워크의 장비에 장애 복구를 위한 제어 메시지를 전송하는 단계를 포함하고,
    상기 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득하는 단계는, 상기 장애 감지 메시지에 포함된 장애 포트 정보에 기초하여 장애가 발생한 경로를 판단하고, 장애 발생 이전에 미리 구축된 상기 제1 네트워크의 장비들과 상기 제2 네트워크의 장비들의 매핑 정보에 기초하여, 판단된 장애 경로와 연관된 제1 네트워크 장비에 대응되는 제2 네트워크의 장비 정보를 획득하는 것을 특징으로 하는 장애 처리 방법.
  16. 청구항 15에 있어서,
    상기 장애 발생 정보는 발생된 장애와 연관된 포트 정보 및 상기 제1 네트워크 내의 장애 발생 유무 정보 중 적어도 하나의 정보를 포함하는 것을 특징으로 하는 장애 처리 방법.
  17. 삭제
  18. 청구항 15에 있어서,
    상기 장애 경로와 연관된 제2 네트워크의 장비 정보를 획득하는 단계는, 상기 획득한 제2 네트워크 장비의 장애와 연관된 포트 및 상기 포트와 연관된 네트워크 매핑 정보를 획득하는 것을 특징으로 하는 장애 처리 방법.
  19. 청구항 18에 있어서,
    상기 제어 메시지를 전송하는 단계에서는, 상기 장애 경로와 연관된 제2 네트워크 장비에서 장애와 연관된 포트를 비활성화하거나, 상기 포트와 연관된 VLAN(Virtual Local Area Network)을 비활성화하기 위한 제어 메시지를 전송하는 것을 특징으로 하는 장애 처리 방법.
KR1020140074011A 2013-06-28 2014-06-18 통신 네트워크에서 경로 장애 처리 방법 KR102111330B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20130076097 2013-06-28
KR1020130076097 2013-06-28

Publications (2)

Publication Number Publication Date
KR20150002475A KR20150002475A (ko) 2015-01-07
KR102111330B1 true KR102111330B1 (ko) 2020-05-15

Family

ID=52475869

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140074011A KR102111330B1 (ko) 2013-06-28 2014-06-18 통신 네트워크에서 경로 장애 처리 방법

Country Status (1)

Country Link
KR (1) KR102111330B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117898015A (zh) * 2021-09-24 2024-04-16 苹果公司 Ue到nw侧链路中继中的多路径操作

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009135731A (ja) * 2007-11-30 2009-06-18 Fujitsu Ltd 無線ネットワーク制御装置およびその障害処理方法
JP2011091657A (ja) * 2009-10-23 2011-05-06 Hitachi Ltd 光伝送システム
KR101120322B1 (ko) * 2004-06-18 2012-03-06 에이저 시스템즈 인크 데이터 보호 방법, 네트워크 프로세서, 멀티서비스 액세스노드 및 라우터

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100582541B1 (ko) * 2003-08-21 2006-05-23 한국전자통신연구원 수동광네트워크에서의 망종단장치 및 장애처리방법
KR20080089285A (ko) * 2007-03-30 2008-10-06 한국전자통신연구원 이더넷 링 네트워크에서의 보호 절체 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101120322B1 (ko) * 2004-06-18 2012-03-06 에이저 시스템즈 인크 데이터 보호 방법, 네트워크 프로세서, 멀티서비스 액세스노드 및 라우터
JP2009135731A (ja) * 2007-11-30 2009-06-18 Fujitsu Ltd 無線ネットワーク制御装置およびその障害処理方法
JP2011091657A (ja) * 2009-10-23 2011-05-06 Hitachi Ltd 光伝送システム

Also Published As

Publication number Publication date
KR20150002475A (ko) 2015-01-07

Similar Documents

Publication Publication Date Title
EP2680510B1 (en) Service plane triggered fast reroute protection
JP4682887B2 (ja) 故障復旧方法およびノードならびにネットワーク
US8456982B2 (en) System and method for fast network restoration
JP6278818B2 (ja) 中継システムおよびスイッチ装置
KR20150051107A (ko) 신속한 경로 설정 및 장애 복구 방법
JP5521663B2 (ja) 通信装置、通信システムおよび通信方法
EP2866394B1 (en) Method and device for sending inter-domain fault information
JP2009303092A (ja) ネットワーク装置および回線切替方法
Chiesa et al. A survey of fast recovery mechanisms in the data plane
KR102157711B1 (ko) 통신 네트워크에서 장애 복구 방법
US10033573B2 (en) Protection switching method, network, and system
EP2965467A1 (en) A network element for a telecommunications network having decoupled control and data planes
JP5618946B2 (ja) 通信装置および通信システム
US8767736B2 (en) Communication device, communication method, and recording medium for recording communication program
KR102111330B1 (ko) 통신 네트워크에서 경로 장애 처리 방법
Huynh et al. RRR: Rapid ring recovery submillisecond decentralized recovery for ethernet ring
JP5518771B2 (ja) 冗長ネットワークシステム、終端装置及び中継点隣接装置
JP4541367B2 (ja) 故障救済方法およびパケット通信装置
KR101726264B1 (ko) 이기종 패킷전달망간 연동을 위한 통합 네트워크 관리 시스템 및 그 방법
WO2017010078A1 (ja) 制御装置、障害通知方法及び記録媒体
JP5752645B2 (ja) マルチキャスト転送システムおよびマルチキャスト経路切替方法
JP2009253874A (ja) 冗長プロトコル共存システム及び転送装置
JP2011234141A (ja) ネットワーク機器、冗長ネットワーク及びそれに用いるループ回避方法
James Applying ADM and OpenFlow to Build High Availability Networks
Weingarten et al. Applicability of MPLS transport profile for ring topologies

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant