KR100701105B1 - Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법 - Google Patents

Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법 Download PDF

Info

Publication number
KR100701105B1
KR100701105B1 KR1020040110352A KR20040110352A KR100701105B1 KR 100701105 B1 KR100701105 B1 KR 100701105B1 KR 1020040110352 A KR1020040110352 A KR 1020040110352A KR 20040110352 A KR20040110352 A KR 20040110352A KR 100701105 B1 KR100701105 B1 KR 100701105B1
Authority
KR
South Korea
Prior art keywords
control channel
node
message
state
protection
Prior art date
Application number
KR1020040110352A
Other languages
English (en)
Other versions
KR20060071669A (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 한국전자통신연구원
Priority to KR1020040110352A priority Critical patent/KR100701105B1/ko
Priority to US11/264,086 priority patent/US7548510B2/en
Publication of KR20060071669A publication Critical patent/KR20060071669A/ko
Application granted granted Critical
Publication of KR100701105B1 publication Critical patent/KR100701105B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/14—Monitoring arrangements

Abstract

본 발명은 IP 기반 네트워크 환경에서 고신뢰도의 제어 네트워크를 구성하는 방법에 관한 것으로서, 자동 제어채널 구성/보호(Automatic Control Channel Configuration and Protection)를 위한 프로토콜 기술을 제시한다. 본 발명은 세부적으로 보호 그룹(Protection Group)-1/3의 제어채널 식별, 보호 그룹(Protection Group)-2의 제어채널 식별, 자동 절체, 강제 절체, 보호/절체 속성 정보 질의, 제어채널 불가용성 통보, 헬로우, 프로토콜 오류 통보, 그리고 재전송 기능으로 구성되며, 제어채널 보호/절체 기술을 적용하지 않는 일반 기술과 제어채널 보호/절체 기술을 적용한 진보 기술, 보호/절체 기술의 적용시 우선순위를 고려한 유니캐스팅 절체 방식과 우선순위를 고려하지 않은 멀티캐스팅 절체 방식을 선택적으로 지원하며, 특히, 멀티캐스팅 절체시 "스탠바이 제어채널의 수 - 1"만큼의 링크 장애도 감내할 수 있다.

Description

ＩＰ 기반 네트워크에서 제어채널 구성 및 보호 방법과 상태 천이 방법{Method for configuration and protection of control channel in IP-based network and method of status transition therefor}
도 1은 IP 기반 네트워크 개념도를 도시한 도면,
도 2는 본 발명이 적용되는 제어 네트워크의 신호관계 구성도,
도 3은 본 발명에 따른 광인터넷의 제어방식 프로토콜 스택을 도시한 도면,
도 4는 본 발명에 따른 광인터넷 시스템에서 링크관리 프로토콜, 라우팅 프로토콜, 그리고 신호방식 프로토콜과 관련한 개괄적인 처리 과정을 도시한 도면,
도 5는 본 발명에 따른 자동 제어채널 구성/보호를 위해 적용되는 기능 구성도를 도시한 도면,
도 6은 본 발명에 다른 자동 제어채널 구성/보호를 위해 적용되는 보호/절체 테이블 구성도를 도시한 도면,
도 7은 본 발명에 따른 자동 제어채널 구성/보호를 위해 적용되는 보호/절체 테이블의 변환 과정의 일 예를 기술하기 위해 사용된 샘플 네트워크를 도시한 도면,
도 8은 본 발명에서 사용하는 자동 제어채널 구성/보호를 위한 프로토콜의 상태 정의도를 도시한 도면,
도 9는 본 발명에서 자동 제어채널 구성/보호를 위한 프로토콜에서 사용하는 이벤트들에 대한 정의도를 도시한 도면,
도 10은 도 8의 상태 정의와 도 9의 이벤트 정의를 근간으로 한 본 발명에 따른 자동 제어채널 구성/보호를 위한 프로토콜의 상태 천이도를 도시한 도면,
도 11a 및 도 11b는 본 발명에 따른 두 인접 노드간 자동 제어채널 구성/보호를 위한 프로토콜을 지원하는 메시지 및 객체를 정의한 도면,
도 12a는 아웃옵서비스 상태에서 준비 상태로 천이하는 과정과 이후, evConfigAck 및 evConfigNack 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 12b는 준비 상태에서 evCCDown, evConfig, evNWTimer, evProtError, 그리고 evRetmTimer 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 12c 내지 도 12e는 준비 상태에서 비보호 기능을 지원하기 위해 evConfig, evConfigAck, 그리고 evConfigNack 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 13a 및 도 13b는 액티브 상태에서 evCCDown, evDCConfig, 그리고 evNotify 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 13c는 액티브 상태에서 evSAInqryAck, evSAInqryNack, evSoAttrReq, evSAInqry, 그리고 evNotifyReq 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 14a는 액티브2 상태에서 evCCDown, evSAInqryAck, evSAInqryNack, evSoAttrReq, 그리고 evSAInqry 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 14b 및 도14c는 액티브2 상태에서 evProtError, evHOnTimer, evHello, 그리고 evRetmTimer 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 15는 스탠바이 상태에서 evProtError, evCCDown, evSwitchover, 그리고 evSOReq 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면,
도 16a는 절체대기 상태에서 evProtError, evCCDown, evSwitchoverAck, evSwitchoverNack 그리고 evSwitchoverTimer 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면, 그리고,
도 16b는 절체대기 상태에서 evSwitchover 이벤트를 수신한 다음 진행되는 과정을 도시한 도면이다.
본 발명은 제어채널 구성 및 보호 방법에 관한 것으로, 보다 상세하게는, IP 기반 네트워크에서 고신뢰도의 제어 네트워크 구성을 위한 제어채널 구성 및 보호 방법과 이를 위한 상태 천이 방법에 관한 것이다.
광인터넷에서의 제어방법으로 파이버내(in fiber) 제어방법과, 파이버외(out or fiber) 제어방법이 있으며, 파이버내 제어방법은 단일 데이터 링크 내에서 단일 제어 채널을 구성하며, 파이버외 제어방법은 전용 제어채널을 사용하거나 외부의 일반 IP 망을 사용하여 다수의 데이터 채널에 대한 연결 제어 기능을 수행한다.
이 때, 파이버외 제어방법에서는 특정 제어채널의 장애가 발생한 경우 연결제어 기능의 중단을 방지하기 위한 제어채널 보호가 필요하다. 제어 채널채널 보호는 광인터넷 환경에서 노드간의 안전한 링크관리, 신호방식(signaling) 및라우팅 관련제어방법을 제공할 수 있다.
종래의 광인터넷에서의 제어채널의 보호에 있어서 제어채널이라 함은 SONET/SDH(Synchoronous Optical Network/Synchronous Digital Hierarchy)의 경우에는 Section/RS(Regenerator Section) 또는 Line/MS(Multiplex Section)의 DCC(Data Communication Channel)를 말한다.
종래에는 연관 모드로 직접 연결된 인접 노드간의 제어채널 중 하나의 액티브 제어채널에서 장애가 발생하였을 때 또 다른 액티브 제어채널을 사용하는 방법, 다시 처음부터 제어채널의 활성화 과정을 시작하는 방법, 신호방식 프로토콜(signaling protocol) 또는 라우팅 프로토콜(routing protocol) 등의 제어 패킷을 송신단의 응용 프로토콜 계층 또는 MPLS(Multi Protocol Label Switching) 계층에서 이중으로 복사하여 전송한 후 수신단의 응용 프로토콜 계층 또는 MPLS 계층에서 선착한 제어 패킷은 취하고 후착한 제어 패킷은 폐기하는 방법을 사용하였다.
본 발명이 이루고자 하는 기술적 과제는, 연관 모드, 준연관 모드 및 비연관 모드의 신호 관계를 적용하고, UNI 및 NNI 인터페이스의 링크 관리 프로토콜의 제어채널 관리 기능을 대체하여 고신뢰도의 제어 네트워크 구성 및 보호 방법을 제공 하는 데 있다.
본 발명이 이루고자 하는 다른 기술적 과제는, IP 기반 네트워크에서 안정적인 제어채널 구성 및 보호를 위한 각 노드에서의 상태 천이 방법을 제공하는 데 있다.
상기의 기술적 과제를 달성하기 위한, 본 발명에 따른 IP 기반 네트워크에서 제어채널 구성 및 보호 방법의 일 실시예는, (a) 발신 노드와 착신 노드사이의 제어 채널이 직접 연결되는 연관 모드 및 상기 발신 노드와 상기 착신 노드사이의 제어 채널이 중계 노드를 경유하여 연결되는 비연관모드에서 액티브 및 스탠바이 제어채널들을 확인하고, 상기 스탠바이 제어채널들의 우선순위를 결정하는 단계; (b) 상기 발신 노드와 상기 착신 노드 사이의 제어 채널이 중계 노드들의 액티브 제어 채널들로 구성되는 준연관 모드의 제어 채널을 지정하는 단계; 및 (c) 액티브 제어채널에 장애가 발생한 경우, 상기 스탠바이 제어채널들 중 가장 우선순위가 높은 제어채널 또는 절체 요구에 대해 가장 먼저 응답하는 제어채널로 절체를 수행하는 단계;를 포함한다.
상기의 기술적 과제를 달성하기 위한, 본 발명에 따른 제어채널 구성 및 보호를 위한 상태 천이 방법의 일 실시예는, (a) 초기 상태인 아웃옵서비스 상태에서 제어채널 확인 요청 메시지를 전송하고 준비 상태로 천이하는 단계; (b) 상기 준비 상태에서 상기 제어채널 확인 요청 메시지에 대한 응신으로 제어채널의 유형, 제어채널의 우선순위를 포함하는 응답 메시지를 수신하고, 상기 응답 메시지를 기초로 상기 제어채널의 보호/절체 기능 및 제어채널 유형에 따라 연관 모드 및 준연관 모드에서 제어패킷을 교환할 수 있는 액티브 상태 또는 비연관 모드에서 제어패킷을 교환할 수 있는 액티브2 상태로 천이하는 단계; (c) 상기 액티브 상태 또는 액티브2 상태에서 해당 제어채널이 더 이상 이용 불가능하다는 이벤트 발생시 절체 요구 메시지를 모든 스탠바이 제어채널로 전송하고 상기 아웃옵서비스 상태로 천이하는 단계;를 포함한다.
이로써, 신뢰도가 높은 제어 네트워크가 구성된다.
이하에서, 첨부된 도면들을 참조하여 본 발명에 따른 IP 기반 네트워크에서 제어채널 구성 및 보호방법과 상태 천이 방법에 대해 상세히 설명한다.
도 1은 IP 기반 네트워크 개념도를 도시한 도면이다.
도 1을 참조하면, IP 기반 네트워크는 크게 메트로 코아 네트워크(100), 백본 네트워크(110) 및 메트로 액세스 네트워크(120)가 상호 연결되어 구성된다. 여기서, 메트로 코아 네트워크(100)는 중용량 라우터 등으로 구성되고, 종속 신호를 교환하는 클라이언트 네트워크(120)는 non-MPLS(또는 MPLS) 라우터, 이데넷 스위치, 그리고 RT/COT-MSPP(Remote Terminal 또는 Central Office Terminal - Multi-service Provisioning Platform) 등으로 이루어지며, 주 신호를 교환하는 백본 네트워크(110)는 OXC와 같은 광회선 분배 시스템으로 이루어진다. 네트워크 노드간 인터페이스 관점에서 광인터넷 제어평면은 ITU-T의 규정처럼 UNI(User to Network Interface) 및 NNI(Network to Network Interface)로 분류할 수 있다. 전송망(ASTN, Automatic Switched Transport Network)과 클라이언트 사이에서 제어평면을 통해 자동 연결 제어를 수행하는 것을 UNI라고 하며, ASTN 내부에서 네트워크 제공자간 인터페이스를 E(External)-NNI, 그리고 하나의 네트워크 제공자 내부에서 제어평면 실체간 인터페이스를 I(Internal)-NNI라고 한다.
도 2는 본 발명이 적용되는 제어 네트워크의 신호관계 구성도이다.
도 2를 참조하면, 연관 모드에서는 트래픽 채널처럼 제어채널은 노드 A(200)와 B(210) 사이에 직접 연결되어 있다. 준연관 모드에서는 트래픽 채널이 노드 A(200)와 B(210) 사이에 직접 연결되어 있지만, 제어채널은 노드 A와 B 사이의 다른 노드를 통해 사전에 정의된 고정된 패스로 구성되어 있다. 그리고, 비연관 모드에서는 준연관 모드와 유사하나 제어채널이 시간대 또는 네트워크 조건에 따라 다르게 구성될 수 있다.
본 발명에서 제어채널의 보호/절체를 위한 기술적 요구사항을 해결하기 위해 연관 모드를 보호그룹-1(Protection Group - 1, PG-1)으로, 준연관 모드를 PG-2로, 그리고 비연관 모드를 PG-3로 설정한다. PG간의 우선순위(PPG, Priority of Protection Group)는 본 발명을 통해 동적으로 지정되고, 하나의 PG 내의 제어채널들간 우선순위(PCC, Priority of Control Channel) 역시 본 발명을 통해 동적으로 지정된다.
도 3은 본 발명에 따른 광인터넷의 제어방식 프로토콜 스택을 도시한 도면이다.
도 3을 참조하면, 신호방식(Signaling) 및 라우팅(Routing) 기능을 위한 광인터넷 제어평면의 프로토콜 스택의 구조(300)는 MPLS(Multi-Protocol Label Switching) 프로토콜 스택 구조를 확장 적용하고 링크관리 프로토콜(LMP, Link Manager Protocol)(310)을 새로이 추가한 구조이다.
좀더 세부적으로 살펴 보면, 인접노드 발견(ND,neighborhood detection) 및 서비스 발견(SD,Service Detection) 기능을 수행하거나 장애 위치결정 등을 위해 사용하는 링크관리 프로토콜(LMP,Link Manager Protocol)(310), OSPF(Open Shortest Path First) 및 IS-IS(Interior System to Interior System)와 같은 라우팅 프로토콜(320), 그리고 호/연결 제어를 위해 사용하는 CR-LDP(Constraint based Routing-Label Distribution Protocol) 또는 RSVP-TE(Resource Reservation Protocol-Traffic Engineering)와 같은 신호방식 프로토콜(330)들에 대해 적용 구간에 따라 UNI, NNI 및 GMPLS(Generalized Multi-Protocol Label Switching) 관련 능력을 확장한다.
이러한 상위 프로토콜들에서 생성된 IP 제어패킷은 PPP(Point to Point Protocol) 등의 하위 프로토콜을 사용하여 교환된다. 또한, 전송평면의 특정 타임슬롯을 사용하는 경우에는 HDLC(High-level Data Link Control) 제어기를 사용한다.
여기서 본 발명을 적용할 수 있는 방법으로 두가지가 있다. 기존의 링크관리 프로토콜(LMP)(310) 가운데 제어채널 관리 기능을 본 발명으로 대치하는 것과, LMP 프로토콜을 사용하지 않지만 제어채널 구성 및 보호/절체 기능만이 요구되는 네트워크 환경에서 본 발명을 사용하는 것이다.
도 4는 본 발명에 따른 광인터넷 시스템에서 링크관리 프로토콜(LMP), 라우 팅 프로토콜(OSPF 등), 그리고 신호방식 프로토콜(RSVP-TE 등)과 관련한 개괄적인 처리 과정을 도시한 도면이다.
도 4를 참조하면, UNI 규격은 LMP 기반의 ND/SD 절차, 그리고 CR-LDP 또는 RSVP-TE 기반의 호/연결 제어 절차를 권고하고 있다. 즉, 먼저 인접노드 발견(ND,Neighborhood Ddetection) 절차를 통해 IP 제어채널에 대한 기본적 구성과 링크 연결성의 검증 과정 등을 완료한다(S400). 그리고 서비스 발견(SD,Service Detection) 절차를 통해 신호방식 프로토콜의 버전과 클라이언트 및 백본 네트워크의 전송 특성 등을 교환한다(S410).
이후, 라우팅 프로토콜을 이용하여 링크 상태 및 네트워크 위상 정보를 교환하고, 네트워크 내에서의 종단간 루트를 확인한다(S430). 최종적으로, 호/연결 설정 절차를 수행(S430)한 다음 전달평면을 통해 사용자 정보를 전송한다(S440). 그리고 필요에 따라 호/연결 삭제 절차를 수행한다(S450).
LMP 프로토콜중 ND 과정(S400)은 제어채널 구성 절차, 헬로우(Hello) 시작 절차, 링크 연속성 검증 절차, 그리고 링크 속성 관계 절차로 이루어지며, SD 과정은 신호방식 프로토콜 확인 절차, 라우터 속성 확인 절차, 망투명성 확인 절차, 그리고 망 루팅 다양성 확인 절차로 이루어진다.
NNI 규격은 I(Internal)-NNI와 E(External)-NNI로 분류할 수 있다. 표준화 대상은 E-NNI로 한정되어 있으나, 네트워크의 단순화 등을 이유로 일반적으로 I-NNI를 E-NNI의 부분집합 기능으로 구성한다.
도 5는 본 발명에 따른 자동 제어채널 구성/보호를 위해 적용되는 기능 구성 도를 도시한 도면이다.
도 5를 참조하면, 본 발명은 기능적으로 PG-1/3 제어채널 식별(505), PG-2 제어채널 식별(510), 자동 절체(515), 강제 절체(520), 제어채널 불가용성 통보(525), 보호/절체 속성 정보 질의(530), 헬로우(535), 프로토콜 오류 통보(540), 그리고 재전송(545) 기능들로 구성되어 있다.
PG-1/3 제어채널 식별(505)
이 기능은 PG-1 또는 PG-3 보호그룹에 대해 두 인접 노드가 제어 패킷의 통신 환경을 구성하기 위해 최초로 수행하는 것이다. PG-1 또는 PG-3 보호그룹의 액티브 및 스탠바이 제어채널을 식별하기 위한 절차는 물리적 링크(이하, 제어 링크)의 구성 방법에 따라 다르게 처리한다. 예를 들면, 두 인접 노드간 제어 링크가 점대점 방식인 경우에는 멀티개스팅 스킴을 적용하며, 그 이외의 방식인 경우에는 유니개스팅 스킴을 적용한다. 따라서, 멀티개스팅 스킴을 적용하는 상황에서는 착신지 IP 주소를 사전에 인지하지 않아도 이 절차를 통해 착신지 IP 주소를 확인할 수 있다. 하지만, 유니개스팅 스킴을 적용하는 상황에서는 두 인접 노드가 사전에 착신지 IP 주소를 인지하고 있어야 메시지 교환이 가능하다.
발신 노드는 제어 링크의 구성 방식에 관계없이 가능한 제어채널 모두에 제어채널 식별(Config) 메시지(도 11a 참조)를 전송하고 착신 노드로부터 응답을 대기한다.
착신 노드는 제어채널 식별(Config) 메시지들을 수신한 후, 액티브 및 스탠바이 제어채널(스탠바이 제어채널의 경우는 우선순위까지 포함)을 결정하고 이러한 상황을 제어채널 식별 확인(ConfigAck) 메시지(도 11a 참조)로 응답한다. 여기서 착신 노드는 동일한 발신 노드로부터 다수의 제어채널 식별(Config) 메시지를 수신할 가능성이 있다. 따라서, 액티브 또는 스탠바이 제어채널로 사용 가능할 경우, 제어채널 식별 확인(ConfigAck) 메시지로 응답하고 그렇지 않은 상황에서는 제어채널 식별 비확인(ConfigNack) 메시지(도 11a 참조)로 응답한다. 이러한 확인 또는 비확인 응답 메시지에는 자신의 노드에서 PG-2의 보호그룹도 지원 가능한지 또는 다수의 스탠바이 제어채널을 통한 자동 절체를 지원 가능한지 발신 노드에게 표시할 수 있다.
발신 노드 및 착신 노드는 PG-1 또는 PG-3 보호그룹에 대해 액티브 및 스탠바이 제어채널들을 확인하게 되면 자신의 노드에서 유지하고 있는 해당 제어채널에 대해서 대국 제어채널 식별자(Remote Control Channel ID), 제어채널 유형(예: 액티브, 스탠바이), 액티브 및 스탠바이 제어채널들의 PPG(Priority of Protection Group) 및 PCC(Priority of Control Channel), 그리고 직접 인접 노드가 결정되게 된다. 하지만, 상황에 따라서는 이 절차를 통해서 제어채널이 식별되지 않을 가능성도 있다는 점에 유의한다.
PG-2 제어채널 식별(510)
PG-1/3 제어채널 식별(505) 기능에서 발신 노드 및 착신 노드간 제어채널이 존재하지 않는 상황에 대비하기 위해 선택적으로 이 기능을 수행할 수 있다. 이 기능은 PG-1 또는 PG-3의 액티브 또는 스탠바이 제어채널들을 확인한 후 더욱 강력한 제어 네트워크 환경을 구성하기 위해 PG-2의 제어채널들을 대상으로 한다. 이러한 우회 루트는 본 자동 제어채널 구성/보호를 위한 프로토콜을 사용하여 동적으로 지정한다.
주의할 점은 PG-2 관련 우회 루트(Detour route)는 중계 노드들을 거치는 패스 중 액티브 제어채널 리스트들로 구성하도록 한다는 것이다. 따라서, 별도의 우회 제어채널에 대한 테이블을 유지할 필요가 없다.
우회 루트의 동적 지정을 위해 발신 노드는 중계 노드로 홉카운터(초기값은 '1')와 자신의 노드 식별자 그리고 착신 노드 식별자를 포함한 우회 제어채널 식별(DCConfig) 메시지(도 11a 참조)를 전송한다. 이 경우, 발신 노드에서 모든 제어채널의 확인 절차를 완료하고 착신 노드로 직접 향하는 제어채널을 제외한 다른 액티브 제어채널을 사용해야 한다. 따라서, 다수의 액티브 제어채널이 존재하는 상황에서는 우회 제어채널 식별(DCConfig) 메시지를 해당 제어채널 수만큼 멀티캐스팅 한다는 점에 유의한다.
중계 노드는 우회 제어채널 식별(DCConfig) 메시지를 수신한 후 자신의 노드가 착신 노드가 아님을 확인하고, 착신 노드 방향으로 동 메시지를 릴레이한다. 이 때 발신 노드로부터 수신한 홉카운터를 '1' 증가시키고 자신의 노드 식별자를 추가한다. 메시지를 전송할 때는 다음과 같은 메시지 전송 규칙을 적용한다.
·수신한 홉카운터 값이 최대 홉카운터 값과 동일하거나 초과하였으면 수신한 노드 방향으로 우회 제어채널 비확인(DCConfigNack) 메시지(도 11a 참조)로 응답한다
·이전에 착신 노드 방향으로 메시지를 전송하였거나 발신 노드 방향으로 응 답하였으면 우회 제어채널 비확인(DCConfigNack) 메시지로 응답한다.
·모든 제어채널의 확인 절차를 완료하였는지 확인한다.
·착신 노드로 직접 전송 가능한 액티브 제어채널이 존재할 경우, 이 제어채널로만 메시지를 전송하도록 한다.
·착신 노드로 직접 전송 가능하지 않을 경우, 제어채널 식별(DCConfig) 메시지를 멀티캐스팅 한다.
최종적으로 착신 노드는 가장 처음으로 수신한 우회 제어채널 식별(DCConfig) 메시지를 수신한 경우에만, 우회 제어채널 확인(DCConfigAck) 메시지(도 11a 참조)로 응답할 수 있고, 다른 경우에 대해서는 우회 제어채널 비확인(DCConfigNack) 메시지로만 응답해야 한다. 이러한 우회 제어채널 확인 또는 비확인 응답 메시지에는 수신한 홉카운터 값과 노드 식별자 리스트를 그대로 포함시키고 자신의 노드 식별자 그리고 착신 노드 식별자(DCConfig 메시지의 발신 노드 식별자)를 포함한다.
우회 제어채널 식별 확인 또는 비확인 메시지를 수신한 중계 노드는 수신한 홉카운터 값에서 "1"을 감소하고 자신의 노드 식별자를 삭제한 후 원래의 발신 노드 방향으로 동 메시지를 전송한다. 또한, PG-2에 대한 우회 제어채널 식별 및 확인 메시지로 확인된 제어채널에 대해서는 IP 패킷의 포워딩이 가능하도록 포워딩 테이블을 재구성한다.
결국, 발신 노드 및 착신 노드간 PG-1/2/3의 구성 과정에서 최종적으로 액티브 제어채널로 확인된 제어채널만이 신호방식 및 라우팅 프로토콜의 메시지들을 전 송할 수 있도록 한다.
자동 절체(515)
이 기능은 실제로 액티브 제어채널이 운용 중인 상황에서 장애가 발생한 경우, 스탠바이 제어채널 가운데 가장 높은 우선순위를 갖는 제어채널(유니캐스팅 절체 방식)로 또는 절체 요구에 대해 가장 먼저 응답하는 제어채널(멀티캐스팅 절체 방식)로 자동 절체를 수행하는 과정이다. 유니캐스팅에서 자동 절체를 하는 중요한 조건은 PPG 및 PCC의 복합 우선 순위 규칙을 적용하여 가장 우선순위가 높은 제어채널을 먼저 선정하여 절체를 수행한다는 점이다.
유니캐스팅 방식의 경우, 자동 절체를 요청하는 노드는 절체 메시지(Switchover)(도 11a 참조)를 인접 노드로 전송하고, 특별한 문제가 없는 한 수신 노드는 절체 확인 메시지(SwitchoverAck)(도 11a 참조)로 응답한다. 하지만, 그 절체 메시지(Inquiry)에 대해 성공적 응답을 할 수 없는 경우, 절체 거절 메시지(SwitchoverNack)(도 11a 참조)로 응답한다. 여기서 주의할 것은 절체 요청 메시지(Switchover)의 절체 유형은 "자동 절체"로 표시되어야 한다는 것이다.
자동 절체에서 절체 메시지(Switchover) 및 절체 확인 메시지(SwitchoverAck)의 교환을 위한 또 다른 방법으로서, 멀티캐스팅 방식이 있다. 이는 자동 제어채널 구성/보호를 위한 프로토콜 메시지들중 자동 절체를 요청하는 메시지 또는 이에 대한 응답 메시지는 현재의 액티브 제어채널을 제외한 all standby control channels을 통해 메시지를 다중으로 전송하도록 하는 것이다. 이때 메시지의 다중 전송시 주의할 점은 동일한 메시지의 복사가 아니라 각각의 제어채널에 대 해 절체를 요청한다는 점이다. 이 방법에서는 PCC를 적용할 필요가 없고 하나 이상의 제어채널 장애에 대해서도 또 다른 제어채널을 통한 제어 패킷 교환이 가능한 장점들이 있다.
이러한 유니캐스팅 방식 및 멀티캐스팅 방식의 선택 여부는 제어채널 식별 절차를 통해 사전에 확인되어야 한다.
이후, 하나의 제어채널이 장애로부터 복구할 경우, 제어채널의 연결성을 검증하는 절차(PG-1/3 제어채널의 확인)를 수행해야 한다. 이 단계에서 대상 제어채널이 복구되었음을 표시하는 정보를 기초로 향후 유니캐스팅 및 멀티캐스팅 절차를 선택적으로 지원할 수 있도록 Active 또는 Active2 상태가 아닌 Standby 상태(도 10 참조)로 천이하도록 한다.
강제 절체(520)
이 기능은 자동 절체와 달리 운용 유지 및 보수의 목적으로 관리 시스템에 의한 강제 절체를 수행하는 과정이다. 그리고 자동 절체는 가장 높은 우선순위를 갖는 제어채널(유니캐스팅 절체 방식)로 또는 절체 요구에 대해 가장 먼저 응답하는 제어채널(멀티캐스팅 절체 방식)로 절체를 진행하지만, 강제 절체는 우선순위와는 관계없이 운용자의 판단에 따라 진행하는 절체이다. 따라서, 자동 절체와는 달리 강제 절체에서는 운용자의 요구로 특정 스탠바이 제어채널로 절체를 요청하기 때문에 다수의 스탠바이 제어채널을 통한 강제 절체를 적용할 필요가 없다
강제 절체를 요청하는 노드는 절체 메시지(Switchover)(도 11a 참조)를 인접 노드로 전송하고, 특별한 문제가 없는 한 수신 노드는 절체 확인 메시지 (SwitchoverAck)(도 11a 참조)로 응답한다. 하지만, 그 절체 메시지(Inquiry)에 대해 성공적 응답을 할 수 없는 경우, 절체 거절 메시지(SwitchoverNack)로 응답한다. 여기서 주의할 것은 절체 요청 메시지(Switchover)의 절체 유형은 "강제 절체"로 표시되어야 한다는 것이다.
제어채널 불가용성 통보(525)
이 기능은 우회 루트로 제어채널 절체를 수행한 후 최초 발신 노드, 중계 노드 그리고 최종 착신 노드 방향으로 모든 제어채널이 장애가 발생하여 더 이상의 제어 패킷의 포워딩 기능을 수행할 수 없을 때(일명 Full out-of-service 상태), 이 상태가 발생한 노드의 바로 이전 노드로 사용 가능한 제어채널이 존재하지 않음을 나타내기 위하여 사용한다. 만일 제어채널의 불가용성을 통보 받은 노드가 최초 발신 노드가 아닌 경우, 최초 발신 노드로까지 이러한 과정이 반복된다.
보호/절체 속성 정보 질의(530)
이 기능은 두 인접 노드에서 유지하고 있는 액티브 제어채널에 대한 보호/절체 속성을 확인하는 과정이다.
제어채널의 보호/절체 속성은 액티브 제어 채널(ACC, Active Control Channel) 속성 및 스탠바이 제이 채널(SCC, Standby Control Channel) 속성으로 분류할 수 있다. 따라서,해당 제어채널에 대한 ACC 및 SCC 관련 속성 정보의 교환을 통해 각 노드에서 유지하고 있는 제어채널의 보호/절체 정보가 상호 일치하는지를 확인할 수 있다.
해당 액티브 제어채널의 보호/절체 속성을 요청하는 노드는 질의 메시지 (SOInquiry)를 인접 노드로 전송하고, 수신 노드는 그 제어채널이 유지하고 있는 ACC 속성 및 SCC 속성 정보를 질의 확인 메시지(SOInquiryAck)로 응답한다. SCC는 하나 또는 그 이상이 존재할 수 있다. 그 질의 메시지(Inquiry)에 대해 성공적 응답을 할 수 없는 경우, 질의 거절 메시지(SOInquiryNack)로 응답한다.
헬로우(535)
이 기능은 LMP의 "Hello Initiation" 기능과 거의 동일하다. 하지만, 본 자동 제어채널보호 프로토콜에서는 PG-3 보호그룹에서만 선택적으로 사용 가능하다. 주의할 점은 "Hello" 패킷을 교환하기 위한 사전의 파라미터 협상에서 "HelloInterval" 및 "HelloDeadInterval" 값을 LMP 규정대로 처리할 수 없다는 것이다. 따라서, 이들 값은 수 초를 단위로 수정되어야 하며, 이로 인해 제어 네트워크의 서비스 품질이 저하될 수 있다.
프로토콜 오류 통보(540)
이 기능은 자동 제어채널 구성/보호를 위한 프로토콜을 수행하는 과정중 수신한 메시지 및 객체 등에서 프로토콜 오류가 발생한 경우, 메시지 송신 노드로 프로토콜 오류 상황을 통보하는 한다. 단, 프로토콜 오류 통보 메시지(ProtError)(도 11a 참조)에서 오류가 발생하는 경우에는 메시지 송신 노드로 또 다시 통보하지 않는다.
재전송(545)
이 기능은 LMP의 "재전송" 기능과 동일하다.
도 6은 본 발명에 다른 자동 제어채널 구성/보호를 위해 적용되는 보호/절체 테이블 구성도를 도시한 도면이다.
본 발명에 따른 자동 제어채널 구성/보호를 위해 필요한 사전 규칙은 다음과 같다.
·제어채널의 보호/절체 기능을 지원하기 위해서는 직접 또는 간접 접속을 통해 두 인접 노드간 두 개 이상의 제어채널이 존재해야 한다.
·자동 보호/절체는 장애를 감지한 노드에서 보호/절체를 요청한다. 그리고 만일 두 노드간에 보호/절체 요청에 대한 경쟁이 발생할 경우, 더 높은 노드 식별자를 갖는 노드가 그 경쟁에서 승리한다.
·시스템은 각 노드에 각 제어채널에 대한 전송 매체(예: SDH-RS, SDH-MS, EoS, Ethernet 등) 및 보호그룹(PG-1 또는 PG-3)을 설정해야 한다.
·동일한 보호그룹에 제어채널이 하나뿐인 경우에는 PCC-1로 자동 지정된다.
·두 인접 노드간에 한번 결정된 PPG 및 PCC는 제어 네트워크를 새로이 구성하지 않는 한 지속되며, 인터페이스의 삭제 또는 추가로 인해 기 지정된 PPG 및 PCC, 그리고 보호 속성 정보에 영향을 주지 않는다.
도 6은 상기와 같은 사전 규칙에 따라 인접 노드간 자동 제어채널 구성/보호를 위한 프로토콜을 운용하는 경우, 해당 시스템에서 유지해야 할 테이블로써, 상세 제어채널에 대한 보호/절체 속성 정보는 다음과 같다.
·자국 제어채널 식별자(Local CC)(605): 정적 지정
·대국 제어채널 식별자(Remote CC)(610): 동적 지정
·우회 제어채널(Detour CC)(615): 동적 지정
·전송 매체(Media)(620): 정적 지정
·제어채널 유형(CC Type)(625): 동적 지정
·보호 그룹(PG) 유형(630): 초기에 모든 제어채널을 PG-1 또는 PG-3으로 정적 지정
·보호그룹 우선순위(PPG)(630): 동적 지정
·제어채널 우선순위(PCC)(630): 동적 지정
·인접 노드(A-Node)(635): 동적 지정
·제어채널 상태(CC Status)(640): 동적 지정
도 7은 본 발명에 따른 자동 제어채널 구성/보호를 위해 적용되는 보호/절체 테이블의 변환 과정의 일 예를 기술하기 위해 사용된 샘플 네트워크를 도시한 도면이다.
도 7을 참조하면, 노드 A(700)는 a1, a2, a3 세 개의 제어채널을, 노드 B(710)는 b1, b2 두 개의 제어채널을, 그리고 노드 C(720)는 c1, c2, c3 세 개의 제어채널을 유지하고 있는 것으로 가정한다.
각 노드에서 초기 프로비젼(provision)시 유지하고 있는 테이블 내용은 다음과 같다.
(노드-A)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
a1 SDH-MS 1//
a2 SDH-MS 1//
a3 SDH-MS 1//
(노드-B)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
b1 SDH-MS 1//
b2 SDH-MS 1//
(노드-C)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
c1 SDH-MS 1//
c2 SDH-MS 1//
c3 SDH-MS 1//
다음 절차로 인접 노드간 제어채널을 확인하게 되면 각 노드는 다음과 같은 테이블을 유지하게 된다.
(노드-A)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
a1 b1 SDH-MS Active 1/1/1 B Up
a2 c2 SDH-MS Actibe 1/1/1 C Up
a3 c3 SDH-MS Standby 1/1/2 C Up
(노드-B)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
b1 a1 SDH-MS Active 1/1/1 A Up
b2 c1 SDH-MS Active 1/1/1 C Up
(노드-C)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
c1 b2 SDH-MS Active 1/1/1 B Up
c2 a2 SDH-MS Active 1/1/1 A Up
c3 a3 SDH-MS Standby 1/1/2 A Up
우회 제어채널에 대한 동적 지정 작업을 수행하고 난 후, 각 노드는 다음과 같은 제어 채널 테이블을 유지하게 된다.
(노드-A)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
a1 b1 a2 SDH-MS Active 1/1/1 B Up
a2 c2 SDH-MS Actibe 1/1/1 C Up
a3 c3 a1 SDH-MS Standby 1/1/2 C Up
(노드-B)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
b1 a1 b2 SDH-MS Active 1/1/1 A Up
b2 c1 b1 SDH-MS Active 1/1/1 C Up
(노드-C)
Local CC Remote CC Detour CC Media CC type PG/PPG/PCC A-Node CC status
c1 b2 c2 SDH-MS Active 1/1/1 B Up
c2 a2 SDH-MS Active 1/1/1 A Up
c3 a3 c1 SDH-MS Standby 1/1/2 A Up
도 8은 본 발명에서 사용하는 자동 제어채널 구성/보호를 위한 프로토콜의 상태 정의도를 도시한 도면이다.
도 8을 참조하면, 본 발명에서는 아웃옵서비스(Out-of-service)(810), 준비(Ready)(820), 액티브(Active)(830), 액티브2(Active2)(840), 스탠바이 (Standby)(850), 절체대기(SOWaiting)(860) 등 여섯 개의 상태를 사용한다.
도 8을 참조하면, 아웃옵서비스(Out-of-service) 상태(810)는 제어 채널을 사용할 어떠한 시도가 없는 초기 상태, 준비(Ready) 상태(820)는 제어채널에 대한 구성 및 상호 연결성을 확인하는 상태, 액티브(Active) 상태(830)는 PG-1 또는 PG-2 내의 제어채널을 통해 신호방식 및 라우팅 프로토콜들이 생성하는 제어 패킷을 교환할 수 있는 상태, 액티브2(Active2) 상태(840)는 PG-3 내의 제어채널을 통해 신호방식 및 라우팅 프로토콜들이 생성하는 제어 패킷을 교환할 수 있는 상태, 스탠바이(Standby) 상태(850)는 제어 채널이 제어 패킷을 전송할 수 있는 액티브 제어채널로의 전환을 대기하고 있는 상태, 그리고, 절체대기(SOWaiting) 상태(860)는 액티브 제어채널로 전환하기 위해 절체를 요청한 후 응답을 대기하고 있는 상태이다.
도 9는 본 발명에서 자동 제어채널 구성/보호를 위한 프로토콜에서 사용하는 이벤트들에 대한 정의도를 도시한 도면이다.
도 9는 본 발명에서 필요한 모든 이벤트들을 제시하지 않았으나, 도 5에서 제시된 기능을 수행하기 위해 필요한 이벤트들과 상태 변화를 야기시키는 이벤트들을 중심으로 제시하였다. 도 9의 각 이벤트 정의(900)에서 사용된 메시지는 도 11a에 도시되어 있다.
도 9를 참조하면, 해당 제어채널에 대한 구성이 시작되어야 함을 의미하는 이벤트(evActivate), 해당 제어채널이 더 이상 이용 불가능함을 의미하는 이벤트(evCCDown), 상대노드로부터 "Config" 메시지가 수신되었음을 의미하는 이벤트 (evConfig), 상대노드로부터 "ConfigAck" 메시지가 수신되었음을 의미하는 이벤트(evConfigAck), 상대노드로부터 "ConfigNack" 메시지가 수신되었음을 의힘하는 이벤트(evCofigNack)가 정의된다.
또한, 상대노드로부터 "DCConfig" 메시지가 수신되었음을 의미하는 이벤트(evDDConfig), 상대노드로부터 "DCConfigNack" 메시지가 수신되었음을 의미하는 이벤트(evDCConfigAck), 상대노드로부터 "DCConfigNack" 메시지가 수신되었음을 의미하는 이벤트(evDCConfigNack)가 정의된다.
또한, 헬로우 대(大)간격 타이머가 만료되었음을 의미하는 이벤트(evHDltvTimer), 상대노드로부터 유효한 순서번호를 포함한 "Hello" 메시지가 수신되었음을 의미하는 이벤트(evHello), 헬로우 소(小)간격 타이머가 만료되었음을 의미하는 이벤트(evHltvTimer), 상대노드로부터 "Hello" 메시지를 전송가능하도록 하는 이벤트(evHOnTimer), 상대노드로부터 "Notify" 메시지가 수신되었음을 의미하는 이벤트(evNotify), 상대노드로 "Notify" 메시지를 전송하도록 하는 이벤트(evNotifyReq), 협상대기 타이머가 만료되었음을 의미하는 이벤트(evNWTimer), 상대노드로부터 "ProtError" 메시지가 수신되었음을 의미하는 이벤트(evProtError), 재전송 타이머가 만료되었음을 의미하는 타이머(evRetmTimer)가 정의된다.
또한, 상대노드로부터 "SAInqry" 메시지가 수신되었음을 의미하는 이벤트(evSAInqry), 상대노드로부터 "SAInqryAck" 메시지가 수신되었음을 의미하는 이벤트(evSAInqryAck), 상대노드로부터 "SAInqryNack" 메시지가 수신되었음을 의미하는 이벤트(evSAInqryNack)가 정의된다.
또한, 해당 제어 채널이 더 이상 이용 불가능하거나 운용자의개입을 통해 제어채널의 절체를 수행하도록 하는 이벤트(evSOReq), 상대노드로 "SAInqry" 메시지를 전송하도록 하는 이벤트(evSoAttrReq), 상대노드로부터 "Switchover" 메시지가 수신되었음을 의미하는 이벤트(evSwitchover), 상대노드로부터 "SwitchoverAck" 메시지가 수신되었음을 의미하는 이벤트(evSwitchoverAck), 상대노드로부터 "SwitchoverNack" 메시지가 수신되었음을 의미하는 이벤트(evSwitchoverNack), 절체 타이머가 만료되었음을 의미하는 이벤트(evSwitchoverTimer)가 정의된다.
도 10은 도 8의 상태 정의와 도 9의 이벤트 정의를 근간으로 한 본 발명에 따른 자동 제어채널 구성/보호를 위한 프로토콜의 상태 천이도를 도시한 도면이다.
도 10을 참조하면, 준비(Ready) 상태(1000)에서 evConfig 이벤트 수신시 ConfigAck 메시지 또는 ConfigNack 메시지(도 11a 참조) 발생으로 인해 다양한 천이 과정이 있을 수 있다. 또한, 스탠바이(Standby)(1010) 또는 절체대기(SOWaiting)(1020) 상태에서 evSwitchover 이벤트 수신시 SwitchoverAck 또는 SwitchoverNack 메시지(도 11a 참조) 발생으로 인해 다양한 천이 과정이 있을 수 있다.
도 11a 및 도 11b는 본 발명에 따른 두 인접 노드간 자동 제어채널 구성/보호를 위한 프로토콜을 지원하는 메시지 및 객체를 정의한 도면이다.
도 11a를 참조하면, 기존 LMP 프로토콜의 Hello 메시지는 변경없이 사용하고, Config, ConfigAck, 그리고 ConfigNack 메시지는 제어채널의 보호/절체를 위해 관련 파라미터들을 확장한다. 그 이외의 메시지들은 제어채널의 보호/절체를 위해 새로이 신규 추가된 메시지들이다. 다음은 LMP 프로토콜의 제어채널 관리 기능과 비교하여 자동 제어채널 구성/보호를 위한 프로토콜에서 추가로 확장된 메시지 또는 객체들을 정의한 것으로서 볼드체로 표시하였다.
Config
LMP 프로토콜에서 사용하는 메시지에 추가적으로, 액티브 및 스탠바이 제어채널을 확인하기 위해 PPG_PCC 객체 및 ADDI_INFO_INDICATOR 객체를 확장한 것으로서, 메시지 포맷은 다음과 같다.
<Config Message> ::=
<Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> <PPG_PCC>
<ADDI_INFO_INDICATOR>
이 메시지의 PPG_PCC 객체는 사용하는 제어채널의 PG 유형과 제어채널의 상태(초기, 복구, 비확인 등)만을 표시하고, ADDI_INFO_INDICATOR 객체는 자신의 노드에서 지원 가능한 부가 능력(예: 도메인간 제어채널 구성, 제어채널 보호/절체 기능, PG-2 기능, 유니캐스팅 및 멀티개스팅 절체 등)을 표시한다.
ConfigAck
LMP 프로토콜에서 사용하는 메시지에 추가적으로, PPG_PCC, CC_TYPE, 그리고 ADDI_INFO_INDICATOR 객체를 확장한 것으로서, 메시지 포맷은 다음과 같다.
<ConfigAck Message> ::=
<Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<CC_TYPE> <PPG_PCC> <ADDI_INFO_INDICATOR>
이 메시지의 CC_TYPE 객체는 사용하는 제어채널의 유형(액티브 또는 스탠바이)을 표시하고, PPG_PCC 객체는 PG 유형과 PG 우선순위, 그리고 제어채널의 우선순위를 표시한다.
ConfigNack
LMP 프로토콜에서 사용하는 메시지에 추가적으로, REJECT_CAUSE 그리고 ADDI_INFO_INDICATOR 객체를 확장한 것으로서, 메시지 포맷은 다음과 같다.
<ConfigNack Message> ::=
<Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<CONFIG> <REJECT_CAUSE> <ADDI_INFO_INDICATOR>
이 메시지의 REJECT_CAUSE 객체는 제어채널의 구성에 대한 실패 원인을 표시한다.
DCConfig
우회 제어채널을 식별하기 위해 사용하는 메시지로써, 액티브 및 스탠바이 제어채널을 확인하기 위해 HOP_COUNTER, REMOTE_NODE_ID, 그리고 RELAY_NODE_ID 객체를 포함한 것으로서, 메시지 포맷은 다음과 같다.
<DCConfig Message> ::=
<Common Header> <MESSAGE_ID> <HOP_COUNTER>
<REMOTE_NODE_ID> <RELAY_NODE_ID> [<RELAY_NODE_ID >...]
REMOTE_NODE_ID를 제외한 다른 모든 객체들은 중계 노드에서 변경되었거나 추가된 객체들임에 유의한다.
DCConfigAck
DCConfig 메시지에 대한 positive acknowledgement를 위해 사용하는 메시지로써, HOP_COUNTER 및 RELAY_NODE_ID 리스트 객체는 DCConfig 메시지의 값을 그대로 적용한다. 메시지 포맷은 다음과 같다.
<DCConfigAck Message> ::=
<Common Header> <MESSAGE_ID_ACK> <HOP_COUNTER>
<RELAY_NODE_ID> [<RELAY_NODE_ID >...]
DCConfigNack
DCConfig 메시지에 대한 negative acknowledgement를 위해 사용하는 메시지로써, HOP_COUNTER 및 RELAY_NODE_ID 리스트 객체는 DCConfig 메시지의 값을 그대로 적용한다. 메시지 포맷은 다음과 같다.
<DCConfigNack Message> ::=
<Common Header> <MESSAGE_ID_ACK> <REJECT_CAUSE>
<HOP_COUNTER> <RELAY_NODE_ID> [<RELAY_NODE_ID >...]
Hello
LMP 프로토콜에서 사용하는 메시지의 정의와 동일하다.
Switchover
자동 및 강제 절체를 요청하기 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<Switchover Message> ::=
<Common Header> <MESSAGE_ID> <LOCAL_CCID>
<OLD_LOCAL_CCID> <SWITCHOVER>
SwitchoverAck
자동 및 강제 절체의 요청에 대한 동의를 나타내기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<SwitchoverAck Message> ::=
<Common Header> <MESSAGE_ID_ACK> <LOCAL_CCID>
SwitchoverNack
자동 및 강제 절체의 요청에 대한 거절을 나타내기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<SwitchoverNack Message> ::=
<Common Header> <MESSAGE_ID_ACK> REJECT_CAUSE>
Notify
더 이상의 절체 가능한 우회 제어채널이 존재하지 않음을 표시하기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<Notify Message> ::=
<Common Header> <LOCAL_CCID> < REMOTE_CCID>
SAInqry
인접 노드에서 유지하고 있는 제어채널에 대한 보호/절체 속성을 요청하기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<SAInqry Message> ::=
<Common Header> <MESSAGE_ID> <LOCAL_CCID>
SAInqryAck
해당 제어채널의 보호/절체 속성의 요청에 대한 정보를 통보하기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<SAInqryAck Message> ::=
<Common Header> <MESSAGE_ID_ACK> <ACC_SWITCHOVER_ATTR>
[<SCC_SWITCHOVER_ATTR>]
SAInqryNack
보호/절체 속성의 요청에 대한 거절을 통보하기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<SAInqryNack Message> ::=
<Common Header> <MESSAGE_ID_ACK> <REJECT_CAUSE>
ProtError
수신한 메시지에서 프로토콜 오류를 감지하였음을 통보하기 위해 사용하는 메시지로서, 메시지 포맷은 다음과 같다.
<ProtError Message> ::=
<Common Header> <PROT_ERROR_CODE>
도 11b를 참조하면, 제어채널의 보호/절체 기능을 지원하기 위해 본 발명에서 사용하는 객체들에 대한 포맷팅 규칙은 다음과 같다.
CCID
LMP 프로토콜에서 정의된 객체를 다음과 같이 확장한다.
C-Type = 3, OLD_LOCAL_CCID
CC_ID
CC_ID: 32 비트
이는 스위치오버(switchover)가 발생하기 전에 로컬 노드의 CC_ID를 나타낸다.
MESSAGE_ID
LMP 프로토콜에서 정의된 객체와 동일하다.
NODE_ID
LMP 프로토콜에서 정의된 객체에서 다음과 같이 RELAY_NODE_ID를 추가한다.
C-Type = 3, RELAY_NODE_ID
Node_ID
Node_ID: 32 비트
이는 중계 노드를 표시한다.
CONFIG
LMP 프로토콜에서 정의된 객체와 동일하다.
HELLO
LMP 프로토콜에서 정의된 객체와 동일하다.
CC_TYPE
Class = 21
C-Type = 1
CC_Type (Reserved)
CC_Type: 8 비트
이는 확인되어야 할 제어채널의 유형을 표시한다.
CC_Type = 1, 액티브
CC_Type = 2, 스탠바이
PPG_PCC
Class = 22
C-Type = 1
PG_Tyte PG_Prio CC_Prio CC_OCause
PG_Type: 8 비트,
이는 해당 제어채널이 속해있는 보호그룹 유형을 표시한다.
PG_Type = 1, PG-1
PG_Type = 2, PG-2
PG_Type = 3, PG-3
PG_Prio: 8 비트
이는 해당 PG의 우선순위 값을 표시한다.
CC_Prio: 8 비트
이는 해당 PG 내의 제어채널에 대한 우선순위 값을 표시한다.
CC_OCause: 8 비트
이는 해당 제어채널의 아웃옵서비스 상태 원인을 표시한다.
CC_OCause = 1, 초기 프로비젼
CC_OCause = 2, 장애
CC_OCause = 3, 비확인
CC_OCause = 4, 운용유지 보수 목적
SWITCHOVER
Class = 23
C-Type = 1
SO_TYPE Cause (Reserved)
SO_Type: 8 비트
이는 절체 유형을 표시한다.
SO_Type = 1, 자동 절체
SO_Type = 2, 강제 절체
Cause: 8 비트
이는 절체 원인을 표시하한다.
SO_Type = 1, 자동 절체
Cause = 1, ACC 장애
Cause = 2, 상위 우선순위 제어채널의 복구
SO_Type = 2, 강제 절체
Cause = 1, 운용자 요청
SWITCHOVER_ATTR
Class = 24
C-Type = 1, ACC_SWITCHOVER_ATTR
Local_CC_ID
Remote_CC_ID
Adjacent_Node_ID
PG_Type PG_Prio CC_Prio CC_OCause
CC_Media (reserved)
Detoru_CC_ID
Local_CC_ID: 32 비트
이는 메시지 송신 노드의 제어채널 식별자를 표시한다.
Remote_CC_ID: 32 비트
이는 메시지 수신 노드의 제어채널 식별자를 표시한다.
Adjacent_Node_ID: 32 비트
이는 해당 제어채널이 원격으로 접속된 노드 식별자를 표시한다.
PG_Type: 위 참조
PG_Prio: 위 참조
CC_Prio: 위 참조
CC_OCause: 사용하지 않음
CC_Media: 16 비트
이는 제어채널의 물리적 전송 특성을 표시한다.
CC_Media = 1, SONET section or SDH Regenerator Section (RS)
CC_Media = 2, SONET line or SDH Multiplex Section (MS)
CC_Media = 3, VC-11 or VC-12 SONET/SDH 타임슬롯
CC_Media = 4, VC-3 SONET/SDH 타임슬롯
CC_Media = 5, VC-4 SONET/SDH 타임슬롯
CC_Media = 10, 10/100 이더넷
CC_Media = 15, Giga 이더넷
CC_Media = 20, PoS
CC_Media = 30, WDM
Detour_CC_ID: 32 비트
이는 인접 노드 사이에서 액티브 또는 스탠바이 제어채널이 서비스를 제공하지 못하는 상황에 대비하여 준비한 우회 루트 상의 제어채널을 표시한다. 포맷은 Local_CC_ID 객체와 동일하다.
C-Type = 2, SCC_SWITCHOVER_ATTR
Local_CC_ID: 위 참조
Remote_CC_ID: 위 참조
Adjacent_Node_ID: 위 참조
PG_Type: 위 참조
PG_Prio: 위 참조
CC_Prio: 위 참조
CC_OCause: 사용하지 않음
CC_Media: 위 참조
Local_CC_ID
Remote_CC_ID
Adjacent_Node_ID
PG_Type PG_Prio CC_Prio CC_OCause
CC_Media (reserved)
HOP_COUNTER
Class = 25
C-Type = 1
Hop_Counter (Reserved)
Hop_Counter: 16 비트
이는 인접 노드 사이의 중계 노드들에 대한 홉수를 표시한다.
ADDI_INFO_INDICATOR
Class = 26
C-Type = 1
Addi_Info_Indicator
Addi_Info_Indicator: 32 비트
이는 이 객체를 송신하는 노드가 지원하는 보호/절체 관련 부가 능력들을 표시한다.
Flag 1 (bit 1): 도메인간 제어채널의 구성이 수행된다면 '1'로 표시한다.
Flag 2 (bit 1): 제어채널의 보호/절체 능력이 지원된다면 '1'로 표시한다.
Flag 3 (bit 1): PG-2를 지원할 수 있다면 '1'로 표시한다.
Flag 4 (bit 1): 유니캐스팅 제어채널 절체를 지원한다면 '1'로 표시한다.
Flag 5 (bit 1): 멀티캐스팅 제어채널 절체를 지원한다면 '1'로 표시한다.
Flag 6 to Flag 32: 예약
PROT_ERROR_CODE
Class = 27
C-Type = 1
PE_Type Cause (Reserved)
PE_Type: 8 비트
이는 프로토콜 오류 유형을 표시한다.
Type = 0, 미정의
Type = 1, 메시지 헤더
Type = 2, 객체 헤더
Type = 3, 객체 내용
Cause: 8 비트
Type = 0, 미정의
Error_Code = 0, 미정의
Type = 1, 메시지 헤더
Cause = 0, 미정의
Cause = 1, 미정의 버전
Cause = 2, 미정의 플래그
Cause = 3, 미정의 메시지 유형
Cause = 4, 메시지 길이 오류
Type = 2, 객체 헤더
Cause = 0, 미정의
Cause = 1, 미정의 C-Type
Cause = 2, 미정의 Class
Cause = 3, 메시지 길이 오류
Cause = 4, 객체 순서 오류
Type = 3, 객체 내용
Cause = 0, 미정의
Cause = 1, 미정의 ADDI_INFO_INDICATOR
Cause = 2, 미정의 CC_TYPE
Cause = 3, 미정의 CCID
Cause = 4, 미정의 CONFIG
Cause = 5, 미정의 HELLO
Cause = 6, 미정의 HOP_COUNTER
Cause = 7, 미정의 MESSAGE_ID
Cause = 8, 미정의 NODE_ID
Cause = 9, 미정의 PPG_PCC
Cause = 10, 미정의 REJECT_CAUSE
Cause = 11, 미정의 SWITCHOVER_ATTR
Cause = 12, 미정의 SWITCHOVER_TYPE
REJECT_CAUSE
Class = 28
C-Type = 1
PJ_Type Cause (Reserved)
RJ_Type: 8 비트
이는 거절된 요청 유형을 표시한다.
RJ_Type = 0, 미정의
RJ_Type = 1, Config 관련
RJ_Type = 2, DCConfig 관련
RJ_Type = 3, SAInqry 관련
RJ_Type = 4, Switchover 관련
Cause: 8 비트
RJ_Type = 0/1/2/3/4, 미정의
Error_Code = 0, 미정의
Error_Code = 1, 미정의 제어채널
Error_Code = 2, 더 이상의 제어채널은 존재하지 않음
RJ_Type = 0, 미정의
RJ_Type = 1, Config 관련
RJ_Type = 2, DCConfig 관련
RJ_Type = 3, SAInqry 관련
RJ_Type = 4, Switchover 관련
도 12a 내지 도 16b는 본 발명에 따른 도 8, 도 9, 도 10, 도 11a 및 도11b에서 각각 예시된 상태 정의, 이벤트 정의, 상태 천이도, 그리고 메시지 정의를 근간으로 자동 제어채널 구성/보호를 위한 프로토콜을 수행하기 위해 적용되는 처리 흐름도를 도시한 도면이다.
도 12a 내지 도 12e는 아웃옵서비스 및 준비 상태에서 PG-1 및 PG-3의 제어채널 식별, 프로토콜 오류, 그리고 재전송 기능에 대한 처리 흐름도이다. 도 13a 내지 도 13c는 액티브 상태에서 PG-2의 제어채널 식별, 보호/절체 속성 정보 질의, 제어채널 불가용성 통보, 프로토콜 오류,그리고 재전송 기능에 대한 처리 흐름도이며, 도 14a 내지 도 14c는 액티브2 상태에서 보호/절체 속성 정보 질의, 헬로우, 프로토콜 오류,그리고 재전송 기능에 대한 처리 흐름도이다. 그리고 도 15, 도 16a 및 도 16b는 스탠바이 및 절체대기 상태에서 자동 및 강제 절체, 프로토콜 오류, 그리고 재전송 기능에 대한 처리 흐름도이다.
도 12a는 아웃옵서비스 상태에서 준비 상태로 천이하는 과정과 이후, evConfigAck 및 evConfigNack 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 12b는 준비 상태에서 evCCDown, evConfig, evNWTimer, evProtError, 그리고 evRetmTimer 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 12c 내지 도 12e는 준비 상태에서 비보호 기능을 지원하기 위해 evConfig, evConfigAck, 그리고 evConfigNack 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 12a를 참조하면, 아웃옵서비스 상태에서 제어채널로 사용 가능한 자원에 대해 evActivate 이벤트를 수신하면 Config 메시지를 생성하고 인접 노드로 동 메시지를 전송한 후 응답을 대기한다(도 12a의 S1,S2,S3,S4,S5).
인접 노드로부터 evConfigAck 이벤트를 수신하면 우선 보호/절체 기능을 적용해야 하는지를 확인한 후, 제어채널 유형이 일차형인지 이차형인지를 체크한다(도 12a의 S7,S10). 보호/절체 기능을 적용하고 이차형 제어채널이면 스탠바이 상태로 천이한다(도 12a의 S6,S7,S8,S9,S10,S23).
일차형 제어채널이면 두 노드 모두 PG-2를 지원해야 하는지를 확인한다(도12a의 S11,S12). 만일 어느 노드 하나라도 PG-2를 지원하지 않으면 수신한 메시지 관련 제어채널의 PG가 PG-1인지 또는 PG-3인지를 확인하고, PG-1이면 액티브 상태로 천이한다(도 12a의 S12,S18,S19,S20).
만일 PG-3이면 HOnTimer 타이머를 시작시키고 액티브2 상태로 천이한다(도 12a의 S19,S21,S22). 만일 두 노드 모두 PG-2를 지원하면 이들 인접 노드를 제외한 다른 모든 인접 노드들간의 제어채널들에 대한 구성이 완료되었는지를 체크한다. 구성 동작이 완료되지 않았으면 완료될 때까지 대기하고(도 12a의 S12,S13,S14,S24,S15), 완료되었으면 다른 인터페이스들의 액티브 제어채널(ACC)들을 결정하고 DCConfig들을 생성/전송한다(도 12a의 S14,S15,S16,S17). 그리고 이전 에 제시된 수신한 메시지 관련 제어채널의 PG가 PG-1인지 또는 PG-3인지를 확인하는 과정과 동일하게 처리한다(도 12a의 S18,S19,S20, 또는 S19,S21,S22).
인접 노드로부터 evConfigNack 이벤트를 수신하게 되면 우선 보호/절체 기능을 적용해야 하는지를 확인한 후, 협상 여부가 필요한지를 확인한다. 만일 보호/절체 기능을 적용해야 하고 협상이 필요하면 수정된 결과를 반영하고 Config 메시지를 생성/전송한 후 응답을 대기한다(도 12a의 S25,S26,S27,S28,S29,S39,S40,S41,S42).
만일 협상이 불필요하면 두 노드 모두 PG-2를 지원해야 하는지를 확인한다(도 12a의 S30,S31). 만일 어느 노드 하나라도 PG-2를 지원하지 않으면 아웃옵서비스 상태로 천이한다(도 12a의 S31,S37). 만일 두 노드 모두 PG-2를 지원하면 이들 인접 노드를 제외한 다른 모든 인접 노드들간의 제어채널들에 대한 구성이 완료되었는지를 체크한다(도 12a의 S32,S33). 구성 동작이 완료되지 않았으면 완료될 때까지 대기하고(도 12a의 S33,S38), 완료되었으면 다른 인터페이스들의 액티브 제어채널(ACC)들을 결정하고 DCConfig들을 생성/전송하고 아웃옵서비스 상태로 천이한다(도 12a의 S33,S34,S35,S36,S37).
ConfigAck를 수신하고 보호/절체 기능을 적용하지 않을 경우(도 12c), 메시지를 수신한 제어채널의 유형이 포인트-투-포인트 방식인지를 체크한다(도 12a의 S6,S7,S8, 도 12c의 S1,S2). 만일 포인트-투-포인트 방식이면 액티브 상태로 천이한다(도 12c의 S2,S3). 만일 포인트-투-포인트 방식이 아니면 HOnTimer 타이머를 시작시키고 액티브2 상태로 천이한다(도 12c의 S2,S4,S5).
ConfigNack를 수신하고 보호/절체 기능을 적용하지 않을 경우(도 12d), 협상이 필요하면 수정된 결과를 반영하고 Config 메시지를 생성/전송한 후 상태 변화 없이 처리를 종료한다(도 12a의 S25,S26,S27, 도 12d의 S6,S7,S9,S10,S11,S12). 협상이 필요하지 않으면 아웃옵서비스 상태로 천이한다(도 12d의 S6,S7,S8).
도 12b를 참조하면, 준비 상태에서 evCCDown 이벤트 또는 evNWTimer 이벤트를 수신하면 아웃옵서비스 상태로 천이한다(도 12a의 S5, 도 12b의 1,2, 도 12b의 S38,S39).
evProtError 이벤트를 수신하면 프로토콜 오류에 대한 내부 처리를 수행하지만 상태 변화 없이 처리를 종료한다(도 12a의 S5, 도 12b의 S40,S41,S42).
evRetmTimer 이벤트를 수신하면 재전송할 메시지가 존재하는지를 확인하고, 존재하지 않으면 상태 변화 없이 처리를 종료한다(도 12b의 S43,S44,S45,S51). 하지만, 재전송할 메시지가 존재하면 RetryLimit 카운터를 확인하고 이 값이 규정 값을 초과하였는지를 확인한다(도 12b의 S45,S46,S47). 규정 값을 초과하였으면 제어채널의 상태는 아웃옵서비스 상태로 천이한다(도 12b의 S47,S48). 규정 값을 초과하지 않았으면 메시지를 재전송하고 RetryLimit 카운터를 '1' 증가시킨 후 상태 변화 없이 처리를 종료한다(도 12b의 S47,S49,S50,S51).
evConfig 이벤트를 수신하면 이들 인접 노드 사이에서 NWTimer 타이머가 동작하고 있는지 확인한다. 만일 동작하고 있으면 타이머를 종료시키고 경합 규칙을 체크한다(도 12a의 S5, 도 12b의 S3,S4,S5,S7,S6). 만일 동작하고 있지 않으면 경합 규칙을 체크한다(도 12a의 S5, 도 12b의 S3,S4,S5,S6). 이 경합 규칙에서 현재 의 노드가 승리하면 상태 변화 없이 처리를 종료한다(도 12b의 S6,S8,S9). 이 경합 규칙에서 현재의 노드가 패배하면 보호/절체 기능 적용 여부를 확인한 후 PG-2 지원 여부를 결정하고, 응답 유형을 확인한다(도 12b의 S6,S8,S10,S11,S12,S13).
만일 보호/절체 기능 적용하고 부정 응답으로 처리해야 한다면 메시지를 수신한 제어채널의 PG와 협상 규칙을 확인한 후 ConfigNack 메시지를 생성/전송한다(도 12b의 S10,S11,S12,S13,S14,S30,S31,S32,S33). 이후, 인접 노드간 협상이 필요하지 않으면 아웃옵서비스 상태로 천이하고(도 12b의 S34,S35), 협상이 필요하면 NWTimer 타이머를 시작시킨 후 상태 변화 없이 종료한다(도 12b의 S34,S36,S37). 만일 보호/절체 기능 적용하고 긍정 응답으로 처리해야 한다면 메시지를 수신한 제어채널의 유형이 일차형인지 이차형인지를 체크한다(도 12b의 S10,S11,S12,S13,S14,S15,S16).
이차형 제어채널이면 해당 제어채널의 PG를 결정하고 ConfigAck 메시지를 생성/전송한 후 스탠바이 상태로 천이한다(도 12b의 S16,S17,S18,S19,S20). 일차형 제어채널이면 해당 제어채널의 PG를 확인한다(도 12b의 S16,S21). 만일 PG-1이면 ConfigAck 메시지를 생성/전송한 후 액티브 상태로 천이한다(도 12b의 S22,S27,S28,S29). 만일 PG-3이면 HOnTimer 타이머를 시작시키고 ConfigAck 메시지를 생성/전송한 후 액티브2 상태로 천이한다(도 12b의 S22,S23,S24,S25,S26).
보호/절체 기능을 적용하지 않을 경우(도 12e), 응답 유형을 확인한다(도 12b의 S11, 도 12e의 S13,S14). 부정 응답으로 처리해야 한다면 협상 규칙을 확인한 후 ConfigNack 메시지를 생성/전송한다(도 12e의 S14,S24,S25,S26). 이후, 인접 노드간 협상이 필요하지 않으면 아웃옵서비스 상태로 천이하고(도 12e의 S27,S28), 협상이 필요하면 NWTimer 타이머를 시작시킨 후 상태 변화 없이 종료한다(도 12e의 S27,S29,S30).
긍정 응답으로 처리해야 한다면 메시지를 수신한 제어채널의 유형이 포인트-투-포인트 방식인지를 체크한다(도 12e의 S14,S15,S16). 만일 포인트-투-포인트 방식이면 ConfigAck 메시지를 생성/전송한 후 액티브 상태로 천이한다(도 12e의 S16,S21,S22,S23). 만일 포인트-투-포인트 방식이 아니면 HOnTimer 타이머를 시작시키고 ConfigAck 메시지를 생성/전송한 후 액티브2 상태로 천이한다(도 12e의 S16,S17,S18,S19,S20).
도 13a 및 도 13b는 액티브 상태에서 evCCDown, evDCConfig, 그리고 evNotify 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 13c는 액티브 상태에서 evSAInqryAck, evSAInqryNack, evSoAttrReq, evSAInqry, 그리고 evNotifyReq 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 13a를 참조하면, 액티브 상태에서 evCCDown 이벤트를 수신하면 절체 규칙을 확인한다(도 13a의 S1,S2,S3). 만일 멀티캐스팅 절체이면 인접 노드상의 모든 스탠바이 제어채널을 확인하고 절체를 수행하기 위해 제어채널 수만큼 evSOReq 내부신호를 전송한 후 아웃옵서비스 상태로 천이한다(도 13a의 S4,S8,S9,S7). 만일 유니캐스팅 절체이면 현재의 상황에서 최고 우선순위를 갖는 스탠바이 제어채널을 확인하고 evSOReq 내부신호를 전송한 후 아웃옵서비스 상태로 천이한다(도 13a의 S4,S5,S6,S7).
evDCConfig 이벤트를 수신하면 우회 제어채널에 대한 구성 규칙을 확인한다(도 13a의 S1,S10,S11). 만일 규칙 확인 과정에서 통과하지 못하면 ConfigNack 메시지를 생성/전송하고 상태 변화없이 처리를 종료한다(도 13a의 S12,S24,S25,S19). 만일 규칙 확인 과정을 통과하면 다른 모든 인접 노드들간의 제어채널들에 대한 구성이 완료되었는지를 체크한다(도 13a의 S12,S13). 구성 동작이 완료되지 않았으면 완료될 때까지 대기하고(도 13a의 S14,S20), 완료되었으면 최종 착신 노드로 향하는 직접 패스가 존재하는지를 확인한다(14,15). 만일 존재하지 않으면 수신한 메시지 관련 인접 노드 이외의 다른 노드들과 관련된 모든 액티브 제어채널들로 DCConfig 메시지들을 생성/전송한 후 상태 변화없이 처리를 종료한다(도 13a의 S16,S21,S22). 만일 존재하면 바로 그 패스로 DCConfig 메시지들을 생성/전송한 후 상태 변화없이 처리를 종료한다(도 13a의 S16,S17,S18,S19).
evNotify 이벤트를 수신하면 자신의 노드가 최초 노드인지를 확인한다(도 13a의 S1,S23, 도 13b의 S26). 최초 노드이면 Notify 메시지의 중계를 중단하고 내부 처리를 수행한 후 상태 변화없이 처리를 종료한다(도 13b의 S27,S30,S29). 최초 노드가 아니면 최초 노드 방향으로 Notify 메시지를 중계하고 상태 변화없이 처리를 종료한다(도 13b의 S27,S28,S29).
도 13c를 참조하면, 액티브 상태에서 evProtError 이벤트를 수신하면 프로토콜 오류에 대한 내부 처리를 수행하지만 상태 변화는 없다(도 13a S1, 도 13c의 S17,S18,S3).
evRetmTimer 이벤트를 수신하면 도 12b의 처리 과정과 동일하다(도 13c의 S19,S20,S21,S22,S23,S24,S25,S26,S27).
evNotifyReq 이벤트를 수신하면 Notify 메시지를 생성/전송한 후 상태 변화없이 처리를 종료한다(도 13a의 S1, 도 13c의 S14,S15,S16,S3).
evSAInqryAck 또는 evSAInqryNack 이벤트를 수신하면 운용자에게 통보한 후 상태 변화없이 처리를 종료한다(도 13a의 S1, 도 13c의 S1,S2,S3).
evSoAttrReq 이벤트를 수신하면 SAInqry 메시지를 생성/전송한 후 상태 변화없이 처리를 종료한다(도 13a의 1, 도 13c의 S4,S5,S6,S3).
evSAInqry 이벤트를 수신하면 보호/절체 속성 테이블을 체크하고 응답 유형을 결정한다(도 13a의 1, 도 13c의 S7,S8,S9). 부정 응답이면 SAInqryNack 메시지를 생성/전송한 후 상태 변화없이 처리를 종료한다(도 13c의 S10,S11,S12,S3). 긍정 응답이면 SAInqryAck 메시지를 생성/전송한 후 상태 변화없이 처리를 종료한다(도 13c의 S10,S13,S14,S3).
도 14a는 액티브2 상태에서 evCCDown, evSAInqryAck, evSAInqryNack, evSoAttrReq, 그리고 evSAInqry 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 14b 및 도14c는 액티브2 상태에서 evProtError, evHOnTimer, evHello, 그리고 evRetmTimer 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 14a 내지 도 14c를 참조하면, 액티브2 상태에서 evCCDown 또는 evHDItvTimer 이벤트를 수신한 후 처리 과정은 도 13a의 evCCDown 이벤트를 수신시 의 처리 과정과 동일하며, 액티브2 상태에서 evProtError, evRetmTimer, evSAInqryAck, evSAInqryNack, evSoAttrReq, evSAInqry 이벤트를 수신한 후 처리 과정은 도 13c와 동일하다.
도 14b 및 도 14c를 참조하면, 액티브 상태에서 evHello 이벤트를 수신하면 수신 순서번호를 변경하고 상태 변화없이 처리를 종료한다(도 14a의 S1, 도 14b의 S8,S9,S3).
evHOnTimer 이벤트를 수신하면 Hello메시지를 생성/전송한 후 HItvTimer 및 HDItvTimer 타이머들을 시작하고 상태 변화없이 처리를 종료한다(도 14a의 S1, 도 14b의 S4,S5,S6,S7,S3).
evHItvTimer 이벤트를 수신하면 Hello메시지를 생성/전송한 후 HItvTimer 타이머를 시작하고 변화없이 처리를 종료한다(도 14a의 S1, 도 14c의 S19,S20,S21,S22,S23).
도 15는 스탠바이 상태에서 evProtError, evCCDown, evSwitchover, 그리고 evSOReq 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 15를 참조하면, 스탠바이 상태에서 evCCDown 이벤트를 수신하면 아웃옵서비스 상태로 천이한다(도 15의 S1,S5,S6).
evProtError 이벤트를 수신하면 프로토콜 오류에 대한 내부 처리를 수행하지만 상태 변화 없이 처리를 종료한다(도 15의 S1,S2,S3,S4).
evSOReq 이벤트를 수신하면 Switchover 메시지를 생성/전송한 후 SwitchoverTimer 타이머를 시작하고 절체대기 상태로 천이한다(도 15의 S1,S20,S21,S22,S23,S24).
evSwitchover 이벤트를 수신하면 응답 유형을 확인한다(도 15의 S1,S7,S8). 만일 부정 응답으로 처리해야 한다면 SwitchoverNack 메시지를 생성/전송한 후 상태 변화 없이 처리를 종료한다(도 15의 S9,S17,S18,S19). 만일 긍정 응답으로 처리해야 한다면 SwitchoverAck 메시지를 생성/전송한 후 수신한 메시지 관련 제어채널의 PG가 PG-1, PG-2 또는 PG-3인지를 확인하고, PG-1 또는 PG-2이면 액티브 상태로 천이한다(도 15의 S10,S11,S12,S13,S14). 만일 PG-3이면 HOnTimer 타이머를 시작시키고 액티브2 상태로 천이한다(도 15의 S13,S15,S16).
도 16a는 절체대기 상태에서 evProtError, evCCDown, evSwitchoverAck, evSwitchoverNack 그리고 evSwitchoverTimer 이벤트들을 수신한 다음 진행되는 과정을 도시한 도면이다.
도 16b는 절체대기 상태에서 evSwitchover 이벤트를 수신한 다음 진행되는 과정을 도시한 도면이다.
도 16a를 참조하면, 절체대기 상태에서 evProtError 이벤트를 수신하면 프로토콜 오류에 대한 내부 처리를 수행하지만 상태 변화 없이 처리를 종료한다(도 16a의 S1,S2,S3,S4).
evSwitchoverAck 이벤트를 수신하면 SwitchoverTimer 타이머를 종료하고 절체 결과를 운용자에게 통보한다(도 16a의 S1,S24,S25,S26). 그리고 수신한 메시지 관련 제어채널의 PG가 PG-1, PG-2 또는 PG-3인지를 확인하고, PG-1 또는 PG-2이면 액티브 상태로 천이한다(도 16a의 S27,S28,S29). 만일 PG-3이면 HOnTimer 타이머를 시작시키고 액티브2 상태로 천이한다(도 16a의 S28,S30,S31).
evCCDown, evSwitchoverTimer, 또는 evSwitchoverNack 이벤트를 수신하면 진행되었던 절체의 유형을 체크한다(도 16a의 S1,S5,S6,S7). 강제 절체이면 절체 결과를 운용자에게 통보하고 수신한 이벤트 유형을 확인한다(도 16a의 S7,S23,S13). 이벤트 유형이 evSwitchoverNack이면 스탠바이 상태로 천이한다(도 16a의 S14,S16). 그 이외의 이벤트 유형에 대해서는 아웃옵서비스 상태로 천이한다(도 16a의 S14,S15).
자동 절체이면 절체 규칙을 확인한다(도 16a의 S7,S8). 만일 멀티캐스팅 절체이면 두 인접 노드 사이의 다른 제어채널의 상태를 확인한다(도 16a의 S9,S21). 모두 아웃옵서비스 상태이거나 비확인 상황이 아니면 수신한 이벤트 유형을 확인한다(도 16a의 S22,S13). 모두 아웃옵서비스 상태이거나 비확인 상황이면 D(Degraded)-상태를 선언하고 다른 인접 노드간 인터페이스들에 대해서 영향을 받는 액티브 제어채널이 존재하는지를 확인한다(도 16a의 S22,S17,S18). 존재하지 않으면 수신한 이벤트 유형을 확인한다(도 16a의 S19,S13). 존재하면 evNotifyReq 내부신호를 전송한 후 수신한 이벤트 유형을 확인한다(도 16a의 S19,S20,S13).
만일 유니캐스팅 절체이면 유니캐스팅 절체이면 현재의 상황에서 최고 우선순위를 갖는 스탠바이 제어채널을 확인한다(도 16a의 S9,S10). 해당 스탠바이 제어채널이 존재하면 evSOReq 내부신호를 전송한 후 이벤트 유형을 확인한다(도 16a의 S11,S12,S13). 해당 스탠바이 제어채널이 존재하지 않면 D(Degraded)-상태를 선언하고 다른 인접 노드간 인터페이스들에 대해서 영향을 받는 액티브 제어채널이 존 재하는지를 확인한다(도 16a의 S11,S16,S17).
도 16b를 참조하면, 절체대기 상태에서 evSwitchover 이벤트를 수신하면 경합 규칙을 확인한다(도 16a의 S1, 도 16b의 S1,S2). 이 경합 규칙에서 현재의 노드가 승리하면 상태 변화 없이 처리를 종료한다(도 16b의 S3,S4). 이 경합 규칙에서 현재의 노드가 패배하면 응답 유형을 확인한다(도 16b의 S3,S5). 이후의 처리 과정은 도 15와 동일하다.
본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으 로 해석되어야 할 것이다.
본 발명에 따르면, 안정적인 제어 네트워크를 구성하기 위해 종래의 PSTN 및 B-ISDN에서 적용하였던 공통선 신호망 개념을 IP 기반 네트워크에 적용한다. 그리고, 종래 제어 채널용도로 MPLS LSP를 설정하여 제어 패킷을 이중으로 복사함으로써 물리적 채널 위에 논리적 제어채널을 구성하는 복잡한 구성과 링크 효율의 저하를 피한다.
또한, IP 기반 네트워크에서 제어채널 및 데이터 채널을 관리하는 프로토콜로써 적용 가능성이 증대되고 있는 링크관리 프로토콜의 제어채널 관리 기능을 제어채널의 보호가 추가된 기능으로 링크관리 프로토콜 내부에서도 사용 가능할 수 있도록 한다.
좀 더 구체적으로 살펴보면, 연관 모드, 준연관 모드 및 비연관 모드의 신호관계를 적용하고, UNI 및 NNI 인터페이스 상에서 링크관리 프로토콜의 제어 채널 관리 기능을 대체하고, 제어채널 보호/절체 기술을 적용하지 않는 일반 기술과 제어채널 보호/절체 기술을 적용한 진보 기술의 선택을 지원한다. 그리고, 보호/절체 기술의 적용시 우선순위를 고려한 유니캐스팅 절체 방식과 우선 순위를 고려하지 않은 멀티캐스팅 절제 방식을 선택할 수 있다.
또한, "스탠바이 제어채널의 수 -1" 크기의 링크 장애를 감내할 수 있으며, 보호 그룹 PG-1/2/3/의 제어채널을 식별하고, 자동 및 강제 절체의 통합을 지원하고, 보호/절체 속성 정보를 검색할 수 있으며, 보호 그룹 PG-2의 제어채널 불가용 성에 대한 통보를 할 수 있다.

Claims (20)

  1. (a) 발신 노드와 착신 노드사이의 제어 채널이 직접 연결되는 연관 모드 및 상기 발신 노드와 상기 착신 노드사이의 제어 채널이 중계 노드를 경유하여 연결되는 비연관모드에서 액티브 및 스탠바이 제어채널들을 확인하고, 상기 스탠바이 제어채널들의 우선순위를 결정하는 단계;
    (b) 상기 발신 노드와 상기 착신 노드 사이의 제어 채널이 중계 노드들의 액티브 제어 채널들로 구성되는 준연관 모드의 제어 채널을 지정하는 단계; 및
    (c) 상기 액티브 제어채널에 장애가 발생한 경우, 상기 스탠바이 제어채널들 중 가장 우선순위가 높은 제어채널 또는 교체 요구에 대해 가장 먼저 응답하는 제어채널로 교체를 수행하는 단계;를 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어 채널 구성 및 보호 방법.
  2. 제 1항에 있어서, 상기 (a) 단계는,
    (a1) 상기 발신 노드에서 상기 연관 모드 및 상기 비연관 모드의 제어채널들을 통해 제어채널 식별 메시지를 착신 노드로 전송하는 단계;
    (a2) 상기 착신노드에서 상기 제어채널 식별 메시지를 수신하고, 액티브 및 스탠바이 제어채널들을 결정하고, 상기 스탠바이 제어채널들의 우선순위를 결정하는 단계; 및
    (a3) 상기 착신노드에서 상기 결정된 액티브 및 스탠바이 제어채널들, 상기 스탠바이 제어채널들의 우선순위 및 상기 준연관 모드 지원여부를 포함하는 응답 메시지를 상기 발신노드로 응답하는 단계;를 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  3. 제 1항에 있어서, 상기 (b) 단계는,
    (b1) 상기 발신노드에서 상기 발신노드와 상기 착신노드 사이에 위치하는 중계노드로 홉카운터, 상기 발신노드의 식별자 및 상기 착신노드의 식별자를 포함하는 우회 제어채널 식별 메시지를 전송하는 단계;
    (b2) 상기 우회 제어채널 식별 메시지를 적어도 하나 이상의 중계노도를 경유하여 상기 착신노드로 전송하는 단계;
    (b3) 상기 우회 제어 채널 식별 메시지가 경유되는 적어도 하나 이상의 중계노드의 각각에서 홉 카운터를 증가하는 단계;
    (b4) 상기 착신노드에서 가장 먼저 수신한 우회 제어채널 식별 메시지에 대한 응답으로 상기 홉카운터, 상기 경유된 중계노드들의 리스트 및 상기 착신노드의 식별자를 포함하는 응답 메시지를 상기 중계노드들을 경유하여 상기 발신노드로 회신하는 단계; 및
    (b5) 상기 응답 메시지가 경유되는 중계노드들에서 상기 홉카운터를 1씩 감소하여 단계;를 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  4. 제 1항에 있어서, 상기 (c) 단계는,
    상기 스탠바이 제어채널 중 가장 우선순위가 높은 제어채널로 교체를 수행하거나, 상기 스탠바이 제어채널들로 교체 메시지를 멀티캐스팅한 후 상기 교체 메시지에 가장 먼저 응답하는 제어채널로 교체를 수행하는 단계;를 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  5. 제 1항에 있어서,
    (d) 상기 장애가 발생한 제어채널이 복구되면, 상기 복구된 제어채널에 대해 상기 연관 모드 및 상기 비연관 모드에서의 연결성을 검증하는 단계;를 더 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  6. 제 1항에 있어서,
    (e) 운용자의 요청에 의해 특정 스탠바이 채널로의 강제 교체를 수행하는 단계;를 더 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  7. 제 1항에 있어서,
    (f) 상기 제어채널의 교체 수행 후, 상기 발신 노드, 상기 중계 노드 및 상기 착신 노드 방향으로 모든 제어채널에 장애가 발생한 경우, 장애가 발생한 바로 이전 노드로 사용 가능한 제어채널이 존재하지 않음을 통보하는 단계;를 더 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  8. 제 1항에 있어서,
    (g) 소정의 제어 채널에 대한 속성 확인 메시지를 인접노드로 전송하고, 상기 속성 확인 메시지에 대한 응답으로 상기 소정의 제어 채널에 대한 속성 정보를 수신하는 단계;를 더 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  9. 제 1항에 있어서,
    (h) 링크 관리 프로토콜의 'Hello' 기능을 수행하는 단계;를 더 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  10. 제 1항에 있어서,
    (i) 메시지 송수신 및 객체에서 프로토콜 오류가 발생한 경우, 상기 발신 노드로 프로토콜 오류를 통보하는 단계;를 더 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  11. 제 1항에 있어서,
    상기 발신노드는 제어채널을 사용할 시도가 없는 아웃옵서비스 상태, 제어채널에 대한 구성 및 상호 연결성을 확인하는 준비상태, 연관 모드 및 비연관 모드내의 제어채널을 통해 제어 패킷을 교환할 수 있는 액티브 상태, 준연관 모드내의 제어채널을 통해 제어 패킷을 교환할 수 있는 액티브2 상태, 제어채널이 제어 패킷을 전송할 수 있는 액티브 제어채널로 전환을 대기하고 있는 스탠바이 상태 및 액티브 제어채널로 전환하기 위해 교체를 요청한 후 응답을 대기하고 있는 교체대기상태를 포함하는 것을 특징으로 하는 IP 기반 네트워크에서 제어채널 구성 및 보호 방법.
  12. (a) 초기 상태인 아웃옵서비스 상태에서 제어채널 확인 요청 메시지를 전송하고 준비 상태로 천이하는 단계;
    (b) 상기 준비 상태에서 상기 제어채널 확인 요청 메시지에 대한 응답으로 제어채널의 유형, 제어채널의 우선순위를 포함하는 응답 메시지를 수신하고, 상기 응답 메시지를 기초로 상기 제어채널의 보호/교체 기능 및 제어채널 유형에 따라 연관 모드 및 준연관 모드에서 제어패킷을 교환할 수 있는 액티브 상태 또는 비연관 모드에서 제어패킷을 교환할 수 있는 액티브2 상태로 천이하는 단계;
    (c) 상기 액티브 상태 또는 상기 액티브2 상태에서 해당 제어채널이 더 이상 이용 불가능하다는 이벤트 발생시 보호/교체 요청 메시지를 스탠바이 제어채널들로 전송하고 상기 아웃옵서비스 상태로 천이하는 단계;를 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  13. 제 12항에 있어서, 상기 (b) 단계는,
    상기 응답 메시지를 기초로 파악한 제어채널의 유형이 스탠바이이면 상기 액티브 제어채널로의 전환을 대기하는 스탠바이 상태로 천이하는 단계;를 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  14. 제 13항에 있어서,
    (d) 상기 스탠바이 상태에서 보호/교체 요청 메시지를 수신하고, 상기 보호/교체 요청 메시지에 해당하는 제어채널이 연관모드 또는 준연관모드이면 상기 액티브 상태로 천이하고, 상기 해당하는 제어채널이 비연관모드이면 상기 액티브2 상태로 천이하는 단계;를 더 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  15. 제 13항에 있어서,
    (e) 상기 스탠바이 상태에서 해당 제어채널의 이용 불가능 또는 운용자에 의한 제어채널 교체 요구 이벤트가 발생하면, 제어채널의 보호/교체 요청 메시지를 생성하여 전송하고 응답을 대기하는 교체대기 상태로 천이하는 단계;를 더 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  16. 제 15항에 있어서,
    (f) 상기 교체대기 상태에서 상기 보호/교체 요청 메시지에 대한 동의 메시지를 수신하고 상기 동의 메시지에 해당하는 제어채널이 연관모드 또는 준연관모드이면 상기 액티브 상태로 천이하고, 상기 동의 메시지에 해당하는 제어채널이 비연관모드이면 액티브2 상태로 천이하는 단계;를 더 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  17. 제 12항에 있어서, 상기 (b) 단계는,
    상기 응답 메시지에 해당하는 제어채널이 보호/교체 기능을 적용하지 않을 경우, 상기 응답 메시지에 해당하는 제어채널이 점대점방식이면 상기 액티브 상태로 천이하고, 점대점방식이 아니면 액티브2 상태로 천이하는 단계;를 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  18. 제 12항에 있어서,
    (g) 상기 준비상태에서 상기 제어채널 확인 요청 메시지에 대한 거절 메시지를 수신하면 제어채널 보호/교체 적용 여부, 협상 필요성 및 준연관모드의 제어채널 지원여부에 따라 상기 아웃옵서비스 상태로 천이하거나 제어채널 확인 요청 메시지를 생성하여 전송하는 단계;를 더 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  19. 제 12항에 있어서,
    (h) 상기 준비상태에서 해당 제어채널의 이용 불가능 또는 프로토콜 오류 또는 협상대기 타이머가 만료되었음을 나타내는 이벤트가 발생하면 상기 아웃옵서비 스 상태로 천이하는 단계;를 더 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
  20. 제 12항에 있어서,
    (i) 상기 준비상태에서 제어채널 확인 요청 메시지를 수신하면 상기 제어채널 확인 요청 메시지에 해당하는 제어채널의 유형, 보호/교체 기능 적용 여부를 기초로 상기 이웃옵서비스 상태, 상기 스탠바이 상태, 상기 액티브 상태 및 상기 액티브2 상태 중 어느 하나의 상태로 천이하는 단계;를 더 포함하는 것을 특징으로 하는 제어채널 구성 및 보호를 위한 상태 천이 방법.
KR1020040110352A 2004-12-22 2004-12-22 Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법 KR100701105B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020040110352A KR100701105B1 (ko) 2004-12-22 2004-12-22 Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법
US11/264,086 US7548510B2 (en) 2004-12-22 2005-10-31 Method of constituting and protecting control channel in IP-based network and status transition method therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020040110352A KR100701105B1 (ko) 2004-12-22 2004-12-22 Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법

Publications (2)

Publication Number Publication Date
KR20060071669A KR20060071669A (ko) 2006-06-27
KR100701105B1 true KR100701105B1 (ko) 2007-03-28

Family

ID=36595587

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020040110352A KR100701105B1 (ko) 2004-12-22 2004-12-22 Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법

Country Status (2)

Country Link
US (1) US7548510B2 (ko)
KR (1) KR100701105B1 (ko)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4454516B2 (ja) * 2005-02-16 2010-04-21 富士通株式会社 障害検出装置
US7957380B2 (en) * 2005-11-21 2011-06-07 Cisco Technology, Inc. Support of unidirectional link in IS-IS without IP encapsulation and in presence of unidirectional return path
EP1804433A1 (en) * 2005-12-30 2007-07-04 Nederlandse Organisatie voor toegepast-natuurwetenschappelijk Onderzoek TNO Initialization of a wireless communication network
US8331243B2 (en) * 2006-02-24 2012-12-11 Rockstar Consortium USLP Multi-protocol support over Ethernet packet-switched networks
CN101047700B (zh) * 2006-05-01 2010-05-12 华为技术有限公司 一种提高lmp控制通道可靠性的方法与装置
CN1878036B (zh) * 2006-07-18 2010-06-09 华为技术有限公司 一种智能光网络中控制层面路由收敛的方法
JP4728209B2 (ja) * 2006-12-05 2011-07-20 アラクサラネットワークス株式会社 マルチキャストネットワーク冗長化システム
US8432909B2 (en) * 2007-04-03 2013-04-30 Ciena Corporation Methods and systems for using a link management interface to distribute information in a communications network
CN101304340B (zh) * 2007-05-09 2011-09-21 华为技术有限公司 一种资源状态监控方法及装置以及通信网络
US9014369B2 (en) * 2010-02-11 2015-04-21 International Business Machines Corporation Voice-over internet protocol (VoIP) scrambling mechanism
EP2666260A1 (en) * 2011-01-21 2013-11-27 Telefonaktiebolaget LM Ericsson (PUBL) Timer value negotiation for path configuration based on rsvp-te
US8553707B2 (en) 2011-03-01 2013-10-08 Ciena Corporation Administrative boundaries in single or multiple domain optical networks
CN105553864B (zh) * 2014-10-31 2020-04-28 中兴通讯股份有限公司 降低lmp中消息数量的方法及装置
CN107634869B (zh) * 2016-07-18 2022-07-15 中兴通讯股份有限公司 一种Hello消息处理方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010025595A (ko) * 2001-01-10 2001-04-06 안병엽 광인터넷에서의 ＭＰλＳ 보호 및 절체방법
KR20030048973A (ko) * 2001-12-13 2003-06-25 엘지전자 주식회사 자동 보호 절체 시스템에서의 절체 방법
KR20040048674A (ko) * 2002-12-04 2004-06-10 한국전자통신연구원 광인터넷의 제어채널 보호방법

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2261323A1 (en) * 1999-02-05 2000-08-05 Newbridge Networks Corporation Backup procedure for dss2-based signalling links
JP3700596B2 (ja) * 2001-03-14 2005-09-28 日本電気株式会社 通信ネットワーク及びパス設定方法並びにパス設定用プログラム
JP3888866B2 (ja) * 2001-08-17 2007-03-07 富士通株式会社 イーサネット伝送路の冗長化システム
JP2003298633A (ja) * 2002-04-05 2003-10-17 Fujitsu Ltd 制御チャネル障害時のデータチャネル障害通知機能を有する伝送装置
US7406082B2 (en) 2002-09-30 2008-07-29 Lucent Technologies Inc. Sequence number schemes for acceptance/rejection of duplicated packets in a packet-based data network
KR100462408B1 (ko) * 2002-12-10 2004-12-17 한국전자통신연구원 Ｇｍｐｌｓ를 통한 빠른 재 루트 방법
US20040153700A1 (en) * 2003-01-02 2004-08-05 Nixon Mark J. Redundant application stations for process control systems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010025595A (ko) * 2001-01-10 2001-04-06 안병엽 광인터넷에서의 ＭＰλＳ 보호 및 절체방법
KR20030048973A (ko) * 2001-12-13 2003-06-25 엘지전자 주식회사 자동 보호 절체 시스템에서의 절체 방법
KR20040048674A (ko) * 2002-12-04 2004-06-10 한국전자통신연구원 광인터넷의 제어채널 보호방법

Also Published As

Publication number Publication date
US7548510B2 (en) 2009-06-16
KR20060071669A (ko) 2006-06-27
US20060133266A1 (en) 2006-06-22

Similar Documents

Publication Publication Date Title
US7548510B2 (en) Method of constituting and protecting control channel in IP-based network and status transition method therefor
US7317731B2 (en) System and method for distributed resource reservation protocol-traffic engineering (RSVP-TE) hitless restart in multi-protocol label switching (MPLS) network
US7428212B2 (en) Best effort technique for virtual path restoration
CA2570333C (en) Method for implementing bidirectional protection switching in multiple protocol label switching network
US7881183B2 (en) Recovery from control plane failures in the LDP signalling protocol
EP1942604B1 (en) A service switching method and the network node thereof
US7274656B2 (en) Protection system and method for resilient packet ring (RPR) interconnection
US8289843B2 (en) Service failure recovery method and system
US7477594B2 (en) Method for restoring a virtual path in an optical network using 1:N protection
CA2382656C (en) Packet network providing fast distribution of node related information and a method therefor
US20080117806A1 (en) Method and device for recovering a shared mesh network
WO2008006268A1 (en) Method system and node device for realizing service protection in the automatically switched optical network
US7764596B2 (en) Method for restoring a virtual path in an optical network using dynamic unicast
US7035209B2 (en) Control communications in communications networks
US20090207845A1 (en) Method and device for avoiding label collision in pbt controlled by gmpls
US7848246B2 (en) Method and system for confirming connection of layer-1 label switched path(L1-LSP) in GMPLS-based network
US20030043427A1 (en) Method of fast circuit recovery using local restoration
US7590051B1 (en) Method and apparatus for redialing a connection on a communication network
EP2117199B1 (en) Transmission method, system and router based on the border gateway protocol
EP1705831B1 (en) Deadlock detection in a telecommunication network
US20200145326A1 (en) Path data deletion method, message forwarding method, and apparatus
JP2006279402A (ja) 通信経路の切替装置、通信経路の切替方法、及び、通信システム
US11490178B2 (en) Method for establishing service path, network device, and system
Boyle et al. Network Hierarchy and Multilayer Survivability
KR20070061201A (ko) 링크 관리 프로토콜을 확장한 상위 계층 연결성 검증시스템 및 방법

Legal Events

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

Payment date: 20130304

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20140303

Year of fee payment: 8

LAPS Lapse due to unpaid annual fee