KR20010085789A

KR20010085789A - 물리층측 디바이스와 네트워크층측 디바이스 사이에데이터를 전송하는 데이터 전송 장치 및 방법

Info

Publication number: KR20010085789A
Application number: KR1020017003221A
Authority: KR
Inventors: 샤오화 위
Original assignee: 추후보충; 우한 리서치 인스티튜트 오브 포스츠 앤드 텔레커뮤니케이션즈, 엠.아이.아이.
Priority date: 1999-07-14
Filing date: 2000-07-13
Publication date: 2001-09-07
Also published as: AU5801400A; US6961348B2; CN1246012A; WO2001006728A1; US20010012288A1

Abstract

본 발명은 물리층측 디바이스와 네트워크층측 디바이스 사이에 데이터를 전송하는 데이터 전송 장치 및 방법을 설명하는 것으로, 이는 가변 SAPI 값을 사용하여 HDLC형 프레임의 SPE/VC에 새로운 LAPS 프레임화(framing)-역프레임화 (deframing)를 캡슐화(encapsulate)한다. LAPS 캡슐화는 시작 플래그 시퀀스(Flag sequence), 어드레스 필드(field)(SAPI, Service Access Point Identifier), 제어 필드(0x03), 정보 필드(Ipv4, Ipv6, 또는 PPP 프로토콜 데이터 유닛), FCS(Frame check sequence), 및 종료 플래그 시퀀스로 구성된다. 플래그 시퀀스(0x7E)는 LAPS 프레임의 시작/종료를 식별한다. 본 발명은 전기통신 하부구조에 인터넷 (Internet)/인트라넷(Intranet)을 적응하는데 사용될 수 있고, 코어 및 엣지 라우터(core and edge router), 스위치 디바이스, IP 근거의 네트워크 억세스 장비, 라인 카드(line card), 및 고속으로 사용되는 인터페이스 유닛, 예를 들면, SDH/SONET, 간략화된 SDH/SONET, 또는 다른 물리층 디바이스에 직접 IP를 적응하기 위한 기가비트 응용(Gigabit application)과 같은 네트워크 디바이스에 적용될 수 있다.

Description

물리층측 디바이스와 네트워크층측 디바이스 사이에 데이터를 전송하는 데이터 전송 장치 및 방법{DATA TRANSMISSION APPARATUS AND METHOD FOR TRANSMITTING DATA BETWEEN PHYSICAL LAYER SIDE DEVICE AND NETWORK LAYER DEVICE}

기존에, Ipv4의 데이터는 IP 프로토콜을 지지하고 IP-관련 응용을 제공하도록 대부분 전기통신 설비 또는 채널을 통해 운송된다. 최상의 채널 중 하나는 SDH이고, 관련된 WDM(wavelength Division Multiplex) 광학 운송 네트워크는 광대역 IP 및 B-ISDN의 물리층에 대한 기본으로 생각된다. SDH/SONET는 최근 수십년 동안 전세계에 걸쳐 모두 전개되었다.

ITU-T G.707은 SDH 및 멀티플렉싱 방법에 의해 제시되는 이점을 설명하고,SDH 비트 비율의 세트, 네트워크 노드 인터페이스(network node interface, NNI)의 일반 원칙 및 프레임 구조, 9행 x N*270열의 전체 프레임 크기, 바이트 할당과 동반되는 섹션 오버헤드(section overhead, SOH), 동기화 운송 모듈(synchronous transport module, STM)의 국제적인 상호연결에 대한 배열, NNI에서 소자를 STM-N으로 멀티플렉싱 및 맵핑(mapping)하는 포맷을 지정한다.

북미에서 SDH와 동일한 것은 SONET이다. SONET는 광학 매체에서 동기화 데이터 전송을 위한 U.S. (ANSI) 표준이다. 사람들은 디지털 네트워크가 국제적으로 상호연결될 수 있고, 현존하는 종래 전송 시스템이 지류로 부착된 것을 통해 광학 매체를 사용할 수 있도록 표준을 보장한다. SONET은 광학적 캐리어 레벨(Optical Carrier Level)이라 공지된 베이스(base) 비율의 배수 세트 및 51.84 Mbps의 베이스 비율을 정의한다. SONET은 표준 비율 및 포맷의 집단군을 정의하는 옥텟(octet)-동기화 다중 구조이다. 그 명칭에도 불구하고, 이는 광학적 링크에 제한되지 않는다. 전기적인 조건은 단일-모드 섬유(fiber), 다중-모드 섬유, 및 CATV 75 ohm 동축 케이블에 대해 정의된다. 전송 비율은 T3/E3 비트-동기화 신호를 운반하는데 사용될 수 있는 51.840 Mbps의 정수배이다. 이는 또한 IP-오버-SDH/SONET의 물리층으로 G.703 E1/E3/E4/T1/E2/T4 인터페이스를 사용하도록 강력하게 추천된다. 이는 LAN을 통해 편리한 사용자 억세스 방법이다.

SDH 및 SONET는 모두 초당 9.953 gigabit(Gbps)인 최대 라인 비율까지의 다수의 라인 비율에 대한 표준을 제공한다. 실제로는 초당 20 gigabit에 접근하는 라인 비율이 가능하다.

인터넷 데이터 통신 서비스를 효과적으로 제공하기 위해 현존하는 거대한 광대역 자원을 어떻게 전체적으로 사용하는가? 더 낮은 비용 및 고속 근거의 프로토콜 모델을 성립하는데 SDH/SONET과 IP-근거의 네트워크를 어떻게 조합하는가? RFC 2225(1998)는 논리적 IP 서브네트워크(Logical IP Subnetwork, LIS)로 구성된 비동기화 전달 모드(asynchronous Transfer Mode, ATM) 네트워크 환경에서 전통적인 IP 및 ARP의 초기 응용을 정의하고, IP 단말-스테이션("멤버 (Member)")과 "전통적인" LAN-근거의 전형예에서 동작하는 라우터를 연결시키는 로컬 LAN 세그먼트 (local LAN segment) 및 "와이어 (wire)"에 대한 직접적인 대치로 ATM의 응용만을 고려한다. RFC 1619(1994)는 SONET 및 SDH 회로를 통한 PPP의 사용을 설명한다. PPP(RFC 1548, 1993)는 포인트-대-포인트 링크를 통해 통신하는 표준적인 방법으로 설계되었다. 초기에는 짧은 로컬선, 임대선, 및 모뎀을 사용하는 POTS(plain-old-telephone service)로 전개되었다. 새로운 패킷(packet) 서비스 및 고속선이 도입됨에 따라, RFC 1717(1994)은 다수의 로컬 데이터 링크를 통해 데이터그램 (datagram)을 분할, 재조합, 및 순차화하는 방법을 제안한다.

인터넷/인트라넷의 고속 성장으로, 텔레콤 인트라넷/인터넷의 프레임워크 (framework) (예를 들면, QoS, 우선순위 (priority), 계좌 관리)를 성립할 필요가 있고, 한편 다른 인터넷/인트라넷 영역에서 기존 인터넷 프로토콜(Ipv4)과 차세대 인터넷 프로토콜(Ipv6)의 호환가능성에 대한 요구조건을 생각할 필요가 있고, 또한 이는 매우 중요하다.

기존에, IP를 SDH/SONET에 적응하는 방법은 RFC 1661, RFC 1662, RFC 1570,RFC 1547, RFC 1340을 포함하는 RFC 2615 프로토콜의 HDLC를 통한 PPP(LCP 및 NCP를 포함하는)이다. PPP는 Ipv4를 포함하여 30 이상의 네트워크 프로토콜을 캡슐화(encapsulate)할 수 있다. 그러나, PPP는 원래 모뎀 다이얼업(방화벽 (firewall)을 위한 프로토콜간 적응에 제안되었으므로, PPP에 대한 알고리즘은 복잡하다.

SONET 또는 SDH를 통해 PPP를 적용할 때, 다음과 같은 결함이 존재한다:

(1) 낮은 레벨의 가상 컨테이너 (container) 응용을 지지하는 표준이 없으므로, SDH/SONET를 통한 IP는 인터넷 엣지 억세스에 적용될 수 없다;

(2) RFC 1691에서는 매우 복잡한 LCP 및 매직 넘버 (Magic Number)가 추천되므로, 2.5 Gbps 비율 이상에서, 하드웨어 포워드 엔진의 오버헤드(overhead)는 특별히, 간략화된 SDH/SONET 프레임을 사용하는 WDM을 통해 IP에 대해 너무 과중하다;

(3) RFC 1619가 사용되는 경우, 재전송 타이머의 디폴트 (default) 값은 PPP에서 3초이므로, 이는 고속 링크에 너무 느리다. 특정한 엔지니어링 응용에서는 2M bit 내지 10000M bit/sec의 모든 비율 범위를 지지할 것이 (약 4032회 변화) 요구되므로, 재전송 타이머의 값은 라인을 따라 왕복 지연을 근거로 결정되어야 한다. 그러나, 이는 RFC 1691에서 정의되지 않으므로, 다른 공급자로부터의 장비를 상호연결할 때 불확실한 일이 일어나게 된다;

(4) PPP의 패딩 (padding) 필드는 SDH/SONET을 통한 IP의 경우 거의 사용되지 않지만, 이는 아직까지 RFC2615에서 유지된다. 부가하여, 이 패딩 필드는 RFC표준에서 정의된 패딩 필드와 정보 필드 사이를 구별하는 기능을 수신기측에서 요구하여, 동시에 처리 오버헤드를 증가시키게 된다;

(5) LCP는 10개의 구성 패킷, 16개 이벤트 (event), 및 12개 작용 (action), 또한 130개 이상의 프로토콜 상태를 포함하여, 광학적 패킷 교환에 실시되기 어렵고 비용이 많이 든다. 상기를 설명하기 위해, 표 1은 유한한 상태의 LCP 기기에서 SONET/SDH 표준을 통한 종래의 PPP를 사용하는 이벤트 및 작용의 리스트를 도시한다.

예를 들어, 도 1은 SDH 라우터를 통한 종래의 PPP에서 라인 카드 구조를 설명한다. 도 1에 도시된 바와 같이, 라우터(1)의 구성성분으로, 다수의 라인 카드(2-1), ..., (2-N)가 있고, 이들 각각은 스위치 패브릭 (switch fabric) 유닛(3)에 연결된다. 각 라인 카드에서, O/E 모듈(5)로부터의 HDLC형 데이터 프레임은 OC-192c/48c/12c/3c 또는 STM-64c/16c/4c/1 송수신기(6)에 의해 수신되어 POS(PPP over SDH/SONET) 맵퍼 (mapper)/디맵퍼 (demapper)(7) (또한 프레이머 (Framer)/디프레이머 (Deframer)라 칭하여지는)에 전송된다. POS 프레이머/디프레이머(7)에서는 HDLC 프레임으로 캡슐화된 PPP 프레임이 추출되고, PPP 처리를 위해 라우팅 엔진 (routing engine)(4)과 협력하여 동작하는 패킷 포워드 엔진(8)으로 전송된다. 라우팅 엔진(4)은 라우터에 삽입된 CPU에 의해 실행되는 소프트웨어이다. 포워드 엔진(8)은 데이터 패킷을 목적지에 전달하도록 라우팅 테이블의 IP 어드레스 서브세트를 조합하는 메카니즘을 사용하거나 라인 카드 식별자에 정보 베이스를 전함으로서, 스위치 패브릭 유닛(3)에 데이터 패킷을 전한다. PPP 기능은 라우터 내부의 각 라인 카드에서 네트워크층 (IP) 처리를 위한 라우팅 엔진 및 포워드 엔진에서 실시된다.

도 2는 종래 라인 카드의 네트워크층에서 PPP 처리의 한 실시를 설명한다. 여기서, 데이터 비율은 예를 들어 2.5Gbit/s인 것으로 가정된다. 도 2에서, PPP (LCP, NCP)의 필터 기능은 포워드 엔진으로, 약 50,000개 이상의 게이트를 갖는 FPGA(field programmable gate array)와 같이, 하드웨어로 실시될 수 있고, 다른 LCP 기능은 라우팅 엔진으로, 소프트웨어 형태로 실시된다. 또는 다른 방법으로, 모든 PPP, LCP, NCP 기능은 포워드 엔진으로 하드웨어로 실시될 수 있고, 이는 약 500,000개 이상의 게이트를 갖는 FPGA가 될 수 있다. 부가하여, PPP 소프트웨어는 10,000개 까지의 C 코드 라인을 가질 수 있고, 수 천불까지의 비용이 든다.

라인 카드(도 1을 참고)에서 네트워크 처리 엔진칩과 맵퍼/디맵퍼 칩의 복잡성과 연관되어, 수개 공급자의 맵퍼/디맵퍼 칩 솔루션을 조사한 후, 본 발명자는다음을 발견하였다:

POS 모드로 구성될 때, 맵퍼/디맵퍼의 전송 HDLC 프로세서는 SPE로의 HDLC 프레임 삽입을 제공한다. 이는 패킷 프레임화, 프레임 사이를 채우는 것, 및 전송 FIFO 에러 회복을 실행하게 된다. 부가하여, 이는 선택적으로 프리 (pre) 또는 포스트 (post) HDLC 프로세서의 스크램블링 (scrambling) (X⁴³+ 1)을 실행하고, RFC 1662에서 지정된 투명성 처리를 실행하고, 또한 선택적으로 16/32 bit FCS를 발생한다.

수신 HDLC 프로세서는 HDLC 프레임의 추출, 투명성 제거, 디스크램블링 (descrambling) (가능하다면), FCS 에러 점검, 및 HDLC 어드레스와 제어 필드의 선택적 삭제를 제공한다. LCP 및 NCP의 기능은 맵퍼/디맵퍼 칩에서 커버되지 않는다.

POS PHY 인터페이스는 OC-3/STM-1에 대해 8 bit 병렬 25Mbps, OC-12/STM-4에 대해 16 bit 병렬 50Mbps, 또한 OC-48/STM-16에 대해 32 bit 병렬 100Mbps 또는 64 bit 병렬로 정의된다.

PPP의 다른 LCP 패킷 처리, 링크 성립 처리, 인증 (Authentication), 네트워크층 프로토콜 위상 및 링크 종결 (Network-Layer Protocol phase and Link Termination), 상태 전이 테이블(state Transition Table)의 형성은 네트워크 프로세서로부터 전달된 글로벌 라우팅 엔진 또는 네트워크 프로세서 엔진에서 실시된다. 많은 공급자, 즉 Agere, Broadcom, Conexant, C-port, IBM, Intel, Lucent,Maker, MMC network, Motorola, Sitera, softcom, TI, 및 Vitesse (일부 유럽, 일본, 및 중국 회사가 또한 포함된다)는 패킷이나 셀 (cell)을 근거로 하는, 또는 패킷 및 셀을 모두 근거로 하는 네트워크 프로세서 엔진을 개발하고 있다. 예를 들어, 일부 회사의 네트워크 프로세서는 현재 이용가능하거나 발매될 예정이고, 이는 800개 이상의 핀의 BGA 패키지를 포함하고, 연관되는 소프트웨어 개발 및 테스트 도구 세트가 또한 라인 카드를 구성하는데 필요하다. 비록 입력 스트림 스케쥴러 (scheduler), 수신 스트림 분석, 룩업 (look-up) 및 업데이트, 수신 편집기, 입력 대기열 (queue) 관리자, 출력 대기열 관리자, 전송 편집기, 출력 스트림 스케쥴러, SSRAM, SDRAM, 및 SNMP 네트워크 관리로의 인터페이스 등과 같이, 이 엔진의 다수의 필요한 기능이 IP 근거의 포워드 처리에 포함되지만, 이 엔진은 다중-프로토콜 프로세서를 가져 매우 복잡하다. 지금까지는 통상적으로 마이크로코드(microcode) 또는 하단층 분류를 근거로 하는 언어의 프로그래밍이 사용된다. 다음 목적은 IP-포워드를 실시하도록 순수한 ASIC를 설립하는 것이다. 상기의 두가지 경우에서, 이는 LCP의 사용을 의미하고, NCP 프로토콜 기능은 IP-근거의 와이어 속도 포워드가 아직 기본 요구이므로 이 엔진이 추가 부담으로 부가됨을 의미한다. 상황이 이전 보다 10배 이상 더 복잡하더라도, 이들 PPP 메카니즘 (즉, Nexabit는 Chicago와 Cleveland 사이에서 OC-192를 통한 PPP를 실시하였다)을 포함하여 모든 기능을 설립하는데 문제가 없는 것으로 믿어진다. 그러나, 비용을 감소시키고 효율성을 높이는 주요점은 종래 설계로부터 얻어질 수 없다.

SDH/SONET 솔루션을 통한 종래의 PPP는 실시하기에 복잡하고, 어렵고, 또한비용이 많이 들며, 느리고, 고속 데이터 전송, 특히 gigabit 비율의 응용에 적접하지 않음을 볼 수 있다.

<발명의 요약>

본 발명의 목적은 간단하고, 효과적이고, 확실하고, 저비용이고, 또한 gigabit 비율 이상을 갖는 라우터 (router) 및 엣지 네트워크 노드에서의 라우터와 같이, 고속 데이터 전송 응용에 적절한 물리층과 네트워크층 사이의 데이터 전송 장치를 제공하는 것이다.

전송 방향에서, 본 발명은 네트워크층측 디바이스로부터 물리층측 디바이스로 데이터 패킷(data packet)을 전송하는 데이터 전송 장치를 제공하고, 이는: 네트워크층측 디바이스로부터 특정한 종류의 데이터 패킷을 수신하는 제1 수신 수단; 데이터 패킷의 종류를 인식하고 인식된 종류에 따라 SAPI 식별자를 발생하는 SAPI 식별자 발생 수단; 제1 타입의 프레임을 형성하도록 시작 플래그(flag), 상기 SAPI 식별자를 포함하는 SAPI 필드(field), 제어 필드, 상기 데이터 패킷을 포함하는 정보 필드, FCS 필드, 및 종료 플래그의 포맷으로 상기 데이터를 캡슐화(encapsulate)하는 제1 프레임화(framing) 수단; 제2 타입의 프레임을 형성하도록 상기 제1 타입의 프레임을 페이로드(payload) 부분으로 캡슐화하고, 적절한 오버헤드(overhead)를 삽입하는 제2 프레임화 수단; 및 상기 제2 타입의 프레임을 물리층측 디바이스에 출력하는 제1 전송 수단을 포함한다.

수신 방향에서, 본 발명은 또한 제1 타입의 프레임을 제2 타입의 프레임에 적절한 오버헤드를 갖는 페이로드로 캡슐화함으로서 형성된 데이터 패킷을 물리층측 디바이스에서 네트워크층측 디바이스로 전송하는 - 상기 제1 타입의 프레임은 각각 시작 플래그, 어드레스 필드, 제어 필드, 정보 필드, FCS 필드, 및 종료 필드를 포함함 - 데이터 전송 장치를 제공하고, 이는: 물리층측 디바이스로부터 데이터 패킷을 수신하는 제2 수신 수단; 오버헤드를 제거하고, 제2 타입의 프레임의 페이로드로부터 제1 타입의 프레임을 추출하는 제2 역프레임화(de-framing) 수단; 제1 타입의 프레임으로부터 정보 필드에 포함된 데이터 및 어드레스 필드를 추출하는 제1 역프레임화 수단; 어드레스 필드(SAPI 필드)의 값을 적어도 제1 값 및 제2 값을 포함하는 미리 설정된 값의 세트와 비교하고, 어드레스 필드 데이터의 값이 제1 값과 정합되면, 추출된 데이터가 제1 타입인 것으로 결정하고, 어드레스 필드의 값이 제2 값과 정합하면, 추출된 데이터가 제2 타입인 것으로 결정하는 결정 수단; 및 추출된 데이터 패킷과 결정 결과를 네트워크층측 디바이스에 전송하는 제2 전송 수단을 포함한다.

본 발명은 또한 전송 및 수신 방향에서 모두 상기의 두가지 데이터 전송을 포함하는 데이터 전송 장치를 구비하여, 네트워크층측 디바이스와 물리층측 디바이스 사이에서 데이터 패킷을 전송하는 데이터 전송 장치를 제공한다.

본 발명은 또한 다수의 라인 카드(line card)를 포함하는 라우터 디바이스를 제공하고, 라인 카드 중 적어도 하나는 전송 및 수신 방향에서 모두 상기의 두가지 데이터 전송을 포함한다.

본 발명은 또한 네트워크층측 디바이스로부터 물리층측 디바이스로 데이터 패킷을 전송하는 데이터 전송 방법을 제공하고, 이는: 네트워크층측 디바이스로부터 특정한 종류의 데이터 패킷을 수신하는 단계; 데이터 패킷의 종류를 인식하고 인식된 종류에 따라 SAPI 식별자를 발생하는 단계; 제1 타입의 프레임을 형성하도록 시작 플래그, 상기 SAPI 식별자를 포함하는 SAPI 필드, 제어 필드, 상기 데이터 패킷을 포함하는 정보 필드, FCS 필드, 및 종료 플래그의 포맷으로 상기 데이터를 캡슐화하는 제1 프레임화 단계; 제2 타입의 프레임을 형성하도록 상기 제1 타입의 프레임을 페이로드 부분으로 캡슐화하고, 적절한 오버헤드를 삽입하는 제2 프레임화 단계; 및 상기 제2 타입의 프레임을 물리층측 디바이스에 출력하는 단계를 포함한다.

본 발명은 또한 제1 타입의 프레임을 제2 타입의 프레임에 적절한 오버헤드를 갖는 페이로드로 캡슐화함으로서 형성된 데이터 패킷을 물리층측 디바이스에서 네트워크층측 디바이스로 전송하는 - 상기 제1 타입의 프레임은 각각 시작 플래그, 어드레스 필드, 제어 필드, 정보 필드, FCS 필드, 및 종료 필드를 포함함 - 데이터 전송 방법을 제공하고, 이는: 물리층측 디바이스로부터 데이터 패킷을 수신하는 단계; 오버헤드를 제거하고, 제2 타입의 프레임의 페이로드로부터 제1 타입의 프레임을 추출하는 제2 역프레임화 단계; 제1 타입의 프레임으로부터 정보 필드에 포함된 데이터 및 어드레스 필드를 추출하는 제1 역프레임화 단계; 어드레스 필드(SAPI 필드)의 값을 적어도 제1 값 및 제2 값을 포함하는 미리 설정된 값의 세트와 비교하고, 어드레스 필드 데이터의 값이 제1 값과 정합되면, 추출된 데이터가 제1 타입인 것으로 결정하고, 어드레스 필드의 값이 제2 값과 정합하면, 추출된 데이터가 제2 타입인 것으로 결정하는 단계; 및 추출된 데이터 패킷과 결정 결과를 네트워크층측디바이스에 전송하는 단계를 포함한다.

본 발명의 데이터 전송 장치 및 방법은 코어 (core) 및 엣지 (edge) 라우터, 스위치 디바이스, IP 근거의 네트워크 억세스 장비, 라인 카드, 및 인터페이스 유닛 등에 적용될 수 있다.

본 발명은 인터넷(Internet)/인트라넷(Intranet)에 관련된 데이터 네트워킹 및 오픈 시스템 통신에 관련된 것으로, 특별히 엣지 라우터(edge router), 스위치 디바이스, IP 근거의 네트워크 억세스 장비, 라인 카드(line card), 및 고속으로 사용되는 인터페이스 유닛, 예를 들어 IP를 SDH/SONET 또는 간략화된 SDH/SONET, 또는 다른 물리측 디바이스에 직접 적응시키는 기가비트(Gigabit) 응용과 같이, 물리층측 디바이스와 네트워크층 디바이스 사이에서 데이터를 전송하는 데이터 전송 장치 및 방법에 관한 것이다.

도 1은 SDH 라우터 (router)를 통한 종래 PPP에서 라인 카드(line card) 구조를 설명하는 도면.

도 2는 종래 라인 카드에서 네트워크층의 PPP 처리 중 한 실시를 설명하는 도면.

도 3A는 본 발명에 따른 네트워크에 대한 프로토콜 스택 (protocol stack)의 구성예를 도시하는 도면.

도 3B는 본 발명에 따라 LAPS를 사용하는 STM-N을 통한 IP에서 층 (Layer)/프로토콜 스택을 설명하는 도면.

도 3C는 본 발명에 따라 LAPS를 사용하는 sSTM을 통한 IP에서 층/프로토콜 스택을 설명하는 도면.

도 4는 본 발명에 따른 LAPS 프레임 포맷을 설명하는 도면.

도 5A 및 도 5B는 네트워크층, 링크층, 및 물리층 사이에 원선 (primitive) 관계를 설명하는 도면.

도 6은 본 발명의 한 실시예에 따라 LAPS를 사용하는 SDH를 통한 IP에서 라우터의 설계를 설명하는 도면.

도 7은 본 발명에 따른 IOSL 프레이머 (framer)/디프레이머 (deframer)의 구조에 대한 한 실시예를 설명하는 도면.

도 8A는 STM-N의 SPE/VC에 대한 구조예를 도시하는 도면.

도 8B는 SDH 및 SONET에서 사용되는 POH (path overhead) 구조를 설명하는 도면.

도 8C는 SPE/VC에서 POH의 위치를 설명하는 도면.

도 9A 및 도 9B는 본 발명에 따른 IOSL 프레이머/디프레이머에서 사용되는 스크램블러 (scrambler) 및 디스크램블러 (descrambler)의 구조를 설명하는 도면.

도 10은 본 발명과 RFC 2615의 프레임 포맷간을 비교하는 도면.

도 11은 본 발명에 따라 SDH 설계를 통한 IP를 사용하는 네트워크 상호연결의 예를 설명하는 도면.

본 발명은 네트워크층 프로세서로부터 필터 기능과 같은 PPP 처리를 제거하고, Ipv6-근거, Ipv4-근거, 및 다른 네트워크 프로토콜 패킷과 같이, 다수의 종류의 데이터를 캡슐화(encapsulate)하도록 SAPI (Service Access Point Identifier)와 다수의 국부적 링크를 수용한다.

LAPS를 사용하는 SDH를 통한 IP는 SDH 네트워크와의 조합 인터넷 프로토콜의 데이터 통신 설계 중 한 종류이다. 도 3A는 본 발명에 따른 네트워크에서 프로토콜 스택 (protocol stack)의 구성예로서, SDH 네트워크를 통한 IP에 LAN (local area network)를 연결시킬 때 입력측 및 출력측의 노드에서 프로토콜 스택 구성을도시한다. 도 3A에 도시된 바와 같이, SDH를 통한 IP는 SDH와 IP의 상호연결을 나타낸다. 게이트웨어 (gateway)에는 SDH 및 MAC 모두의 물리적 인터페이스가 제공되고, 네트워크층은 Ipv4/Ipv6이다.

물리층, 링크층, 및 네트워크층은 도 3A의 STM-N을 통한 IP 및 도 3B의 sSTM-n을 통한 IP에서 층/프로토콜 스택으로 각각 SDH/SONET, LAPS, 및 Ipv4/Ipv6/PPP/IS-IS (중간 시스템)로 지정된다.

도 3A는 본 발명에 따라 LAPS를 사용하는 STM-N을 통한 IP에서 층/프로토콜 스택을 설명한다. 도 3A에 도시된 바와 같이, LAPS를 가상 컨테이너 (virtual container)에 넣는 방법은 2가지가 있다: 한가지는 LAPS 프레임을 저레벨 가상 컨테이너에 넣고, SDH의 멀티플렉스 구조에 따라 인터리브 (interleave) 처리된 옥텟(octet)을 사용하여 저레벨 VC를 고레벨 VC로 멀티플렉스 처리하고, 멀티플렉스 섹션, 재발생 섹션, 및 O/E 전송 섹션의 순차로 전송하면서, 수신측에서 역순차로 LAPS 프레임을 추출하는 것이고; 다른 방법은 LAPS 프레임을 고레벨 컨테이너에 직접 맵핑(mapping)된 SPE에 넣고, 이어서 멀티플렉스 섹션, 재발생 섹션, 및 O/E 전송 섹션의 순차로 전송하면서, 수신측에서 역순차로 LAPS 프레임을 추출하는 것이다.

도 3B는 본 발명에 따라 LAPS를 사용하는 sSTM을 통한 IP에서 층/프로토콜 스택을 설명한다. 도 3B에 도시된 바와 같이, LAPS 프레임은 단지 저레벨 VCx (VC11, VC12, VC2)에 놓이고, SDH의 서브-카테고리 (sub-category) 멀티플렉스 구조에 따라 인터리브 처리된 옥텟을 사용하여 서브-카테고리 멀티플렉스 섹션에 저레벨 VC를 멀티플렉스 처리하고, 멀티플렉스 섹션, 재발생 섹션, 및 O/E 전송 섹션의 순차로 전송하면서, 수신측에서 역순차로 LAPS 프레임을 추출한다.

도 4는 본 발명에 따른 LAPS 프레임 포맷을 설명한다. 도 4에 도시된 바와 같이, LAPS 캡슐화(encapsulation)는 시작 플래그 시퀀스, 어드레스 필드(SAPI, Service Access Point Identifier), 제어 필드(0x03), 정보 필드(Ipv4, Ipv6, 또는 PPP 프로토콜 데이터 유닛), FCS(Frame check sequence), 및 종료 플래그 시퀀스로 구성된다. 플래그 시퀀스(0x7E)는 LAPS 프레임의 시작/종료를 식별한다.

도 5A 및 도 5B는 본 발명의 LAPS와 IP, LAPS, 및 SDH 사이의 원선 (primitive) 관계를 설명한다. 층간의 통신은 원선을 통해 이루어진다. 원선은 추상적인 방식으로 데이터 링크의 층 3 또는 다른 상단 프로토콜 사이에서 정보 및 제어의 논리적 교환을 나타낸다. 이는 실시를 지정하거나 제한하지 않는다. 도 5B에 도시된 바와 같이, DL-UNACK-DATA (요구 및 표시) 원선은 UITS를 사용하여 데이터 링크층 엔터티(entity)에 의해 전송될 또는 수신된 다른 상단 프로토콜의 사용자 데이터 또는 층 3 IP 패킷(사용자 데이터)를 요구하고 표시하는데 사용된다. PH-DATA 원선은 물리층과 전달되는 데이터 링크층 피어(peer)-대-피어 통신에 사용되는 데이터 링크 프레임을 요구하고 표시하는데 사용된다.

MDL-ERROR 원선은 데이터 링크층 피어 엔터티와의 통신 결과로 에러가 발생되었음을 연결 관리 엔터티에 알리는데 사용된다. 그 작용은 MDL-ERROR 표시 원선의 수신시 연결 관리 엔터티에 의해 취해진다. 매개변수는 원선과 연관되고, 서비스와 관련된 정보를 포함한다. DATA 원선의 경우, 매개변수 데이터는 서비스 사용자가 프로토콜 데이터 유닛을 피어 서비스 사용자 엔터티에 전송하도록 허용하는 서비스 데이터 유닛을 포함한다. 예를 들면, DL-UNACK-DATA 매개변수는 층 3 정보를 포함한다. PH_DATA 매개변수는 데이터 링크층 프레임을 포함한다. 예를 들어, 미분 서비스에 대해서는 사용자 데이터 및 6-비트 DS 코드점이 있다.

원선 과정은 서비스를 발동하여 제공하도록 인접한 층 사이의 상호작용을 지정한다. 서비스 원선은 도 5B에 도시된 바와 같이 과정의 요소를 나타낸다.

도 6은 본 발명의 한 실시예에 따라 LAPS를 사용하는 SDH를 통한 IP (이후 IOSL이라 칭하여지는)의 라우터 (router)(도시되지 않은)에서 라인 카드(line card) 구조의 설계를 설명한다. 도 6에 도시된 바와 같이, 라우터는 각각이 특정한 네트워크 노드에 인터페이스 연결되는 다수의 라인 카드(2-1', ..., 2-N'); 라인 카드 사이에서 데이터 패킷을 교환하는 스위치 패브릭 (switch fabric) 유닛(3); OSPF, BGPv4, RIPv1/v2, RSVP, CR-LDP, 시스템 SNMP와 같이, 라우팅 (routing) 처리 및 필요한 네트워크 관리 처리를 실행하는 라우팅 처리 및 네트워크 관리 유닛(4)을 포함한다. 각 라인 카드는 물리층 디바이스에 인터페이스 연결되는 O/E 모듈(5); O/E 모듈과 데이터를 수신/전송하는 OC형 송수신기(6); LAPS 프레임화(framing)/역프레임화(de-framing) 처리를 실행하는 IOSL 프레이머 (framer)/디프레이머 (de-framer)(11); 표준/비율 적응을 위한 네트워크 프로세서(12)내의 FPGA 또는 소프트웨어 코드; 수신 IP 어드레스에 따른 목적지 노드에 IP 패킷을 전하는 네트워크 처리 엔진(8); 표준/비율 적응을 위한 FPGA(13); 스위치 패브릭 유닛(3)과 데이터를 수신/전송하는 직렬 백플레인 (serialbackplane) 송수신기(9)를 포함한다.

도 6에서, O/E는 OC3/12/48/192 비율을 갖는 광학적/전기적 모듈(5)이다. 송수신기(6) OC-3/12/48/192는 2.488Gb/s 데이터 비율로 동작하는 SONET/SDH 시스템에서 사용되는 집적 클럭 발생기와 호환가능한 SONET/SDH 칩이다. 내부 클럭 발생기는 내부 로직 및 출력 재타이밍에 2.488GHz 클럭을 제공하기 위해 77.76MHz 또는 155.52MHz 기준 클럭을 곱하는데 위상 동기 루프를 사용한다. 8/16/32/64 비트 병렬 인터페이스는 탄력적인 병렬 타이밍 설계를 제공함으로서 보드상의 FIFO 제거 루프 타이밍 설계 결과를 포함한다. 부가하여, 디바이스는 설비 및 장비 루프백 (loopback) 모드 및 2개의 루프 타이밍 모드를 제공한다.

도 6에서, IOSL (LAPS를 사용하는 SDH/SONET을 통한 IP) 프레이머/디프레이머는 다음의 기능을 실행한다:

* Ipv4, Ipv6, PPP, IS-IS, 및 에테르넷 (Ethernet) 근거의 패킷을 SAPI에 의해 식별되는 LAPS 정보 필드로 캡슐화한다.

* LAPS의 매개변수 "6-비트 DS 코드점" (RFC 2460에서 정의되는)은 미분화 서비스의 지지를 제공하도록 Ipv4/Ipv6와 LAPS 사이 또는 Ipv4/Ipv6와 PPP 사이에서 일부 링크 기능을 실행하는데 사용될 수 있다; 이는 임의의 LAPS 프레임에 사용되지 않는다. DS 코드점은 IP 데이터로부터 추출되고, 대기열 (queue) 알고리즘을 제어하도록 정보 필드에 놓인다.

* 전송 및 수신 방향에서 모두 운송/섹션 E1, E2, F1, 및 D1-D12 오버헤드 인터페이스로 SONET/SDH 섹션, 라인, 및 경로층의 소스(source) 및 싱크 (sink)를처리한다.

* SONET/SDH 페이로드로의 LAPS 프레임의 전이중 맵핑으로 STS-192/STM-64 또는 STS-48c/STM-16 또는 STS-12c/STM-4 또는 STS-3c/STM-1의 처리를 실시한다.

* LAPS에 대한 (X⁴³+ 1) 다항식을 실시하는 자체-동기화 스크램블러 (scrambler)/디스크램블러 (descrambler).

* POS Phy 인터페이스 또는 유토피아 (Utopia) 인터페이스를 제공한다.

* 사용되는 8-비트 또는 16-비트 마이크로프로세서 인터페이스를 제어, 구성, 및 상태 모니터에 공급한다.

* ITU-T 추천 X.85에 따른 LAPS 처리.

* SONET/SDH 조건 ANSI T1.105에 따른 Bellcore GR-253-CORE 및 ITU G.707 (2000년 4월 버전).

* IEEE 1149.1 JTAG 테스트 포트를 제공한다.

* 증상에 대한 내부 루프백 경로를 지지한다.

상기 IOSL 프레이머/디프레이머에서, 전송 방향으로, 다음의 기본적인 기능이 포함된다: SPE 프레임화에 대한 LAPS 프레임의 삽입; 프레임 사이를 채우는 것과 전송 FIFO 에러의 회복; (X⁴³+ 1)을 스크램블 처리; 투명성 처리; 32 비트 FCS 발생.

수신 방향에서는 기본적인 기능이 다음과 같다: LAPS 프레임의 추출; 투명성 제거; (가능한 경우) 디스크램블 처리; FCS 에러 점검; LAPS 어드레스 및 제어 필드를 삭제.

본 발명의 한 실시예에 따라 도 6에서 IOSL 프레이머/디프레이머의 상세한 구조는 도 7에 도시된다. 프레이머/디프레이머는 전송 및 수신 방향에 대해 모두 표준적인 STS-3c/STM-1 처리를 실행한다.

전송 방향에서, LAPS 프레임은 SONET/SDH SPE/VC로 캡슐화된다. POH 및 TOH/SOH가 삽입되고, 결과의 STS 신호는 병렬/직렬 변환기 및 광섬유 송수신기에 바이트폭 포맷으로 전송된다. 도 7에 도시된 바와 같이, IOSL 프레이머/디프레이머는: 전송 방향에서, 네트워크층측 디바이스로부터의 데이터 패킷, 예를 들면 Ipv4나 Ipv6에 따른 IP 패킷, 또는 PPP 패킷, 또는 IS-IS 등을 수신하여 버퍼 처리하는 TX FIFO(18); 수신된 데이터 패킷의 종류를 결정하고 대응하는 소정의 SAPI 값을 발생하는 SAPI 결정 유닛(19); 도 4에 도시된 포맷에 따라 LAPS 프레임으로 SAPI 및 데이터 패킷을 캡슐화하는 TX LAPS 처리 유닛(22); LAPS 프레임에 대한 스크램블링 유닛(23); SPE/VC4의 위치를 나타내는 포인터를 조정하는 SPE/VC 포인터 조정 유닛; 적절한 오버헤드를 삽입하는 SDH 오버헤드 삽입 유닛(33); SDH/SONET 프레임을 형성하도록 스크램블 처리된 LAPS 프레임을 SDH/SONET 프레임의 SPE/VC4로 캡슐화하는 TX SDH/SONET 프레이머(25); 도 6의 O/E 모듈과 같이, 물리적층 디바이스에 TX 라인을 통하여 SDH/SONET 프레임을 전송하는 라인 인터페이스(26)를 포함한다.

수신 방향에서는 그 처리가 반대이다. 바이트폭 STS 신호가 수신되고, IOSL 프레이머/디프레이머(11)는 프레임 및 TOH/SOH의 위치를 저장하고, 포인터를 해석하고, TOH/SOH 및 POH를 종결짓고, SPE/VC4를 추출하고, 이어서 SPE/VC4 페이로드로부터 LAPS 프레임을 추출한다. SONET/SDH 프로세서는 수신 SONET/SDH 프로세서 및 전송 SONET/SDH 프로세서로 구성된다. 도 7에 도시된 바와 같이, IOSL 프레이머/디프레이머는: 물리층측 디바이스로부터 SDH/SONET 프레임 (HDLC형 프레임)을 수신하는 라인 인터페이스(26); SDH/SONET 프레임을 역프레임화하는 RX SDH/SONET 디프레이머(27); 오버헤드를 제거하는 SDH 오버헤드 추출 유닛(34); 포인터의 위치를 정하여 해석하고, SPE/VC4를 추출하고, SPE/VC4로부터 LAPS 프레임을 분리하는 포인터 해석 유닛(28); 추출된 LAPS 프레임을 디스크램블 처리하는 디스크램블 유닛(29); LAPS 프레임을 역프레임화하고, LAPS 프레임에 캡슐화된 데이터 패킷 및 SAPI를 추출하는 RX LAPS 처리 유닛(30); 및 데이터 패킷을 버퍼 처리하고, 데이터 패킷, 예를 들면 IP 패킷과 SAPI 값을 네트워크층측 디바이스, 예를 들면 도 6의 네트워크 처리 엔진(8)에 전달하는 RX FIFO(20)를 포함한다. IOSL 프레이머/디프레이머(11)는 또한 수신측에서 재전송이 필요한가를 결정하는 연결 관리 유닛(36)을 포함한다.

IOSL 프레이머/디프레이머는 또한 POH를 모니터하는 POH 모니터; SOH를 모니터하는 SDH 오버헤드 모니터; 제어 CPU에 인터페이스 연결하는 마이크로프로세서 I/F(40); 테스트 목적의 JTAG 포트; 및 동작 레지스터를 제공하는 GPIO 레지스터를 포함하고, 이들은 이후에 각각 대응하는 부분에서 설명된다.

이후에는 HDLC형 데이터에 대해 프레이머/디프레이머에서의 수신 및 전송 처리가 상세히 설명된다. 이후의 설명에서, 관련된 기능 또는 동작과 기능 블록 또는 유닛은 실행가능한 프로그램 및/또는 하드웨어 설계의 형태로 실시될 수 있고, 여기서는 본 발명의 주목적을 불필요하게 흐리는 것을 방지하도록 그 설명이 생략된다.

HDLC형 프레임의 구조

도 8A는 HDLC 프레임의 구조예를 설명한다. 도 8A에 도시된 바와 같이, 261 Byte x 9 Row의 페이로드(SPE/VC)가 있고, SDH/SONET 오버헤드로는 재발생 섹션 오버헤드, AU (administration unit) 포인터, 및 멀티플렉스 섹션 오버헤드가 있다. AU 포인터 부분은 페이로드의 시작 위치를 나타내는 H1, H2 바이트를 포함한다. RSOH 부분은 프레임의 위치를 정하는 A1, A2 바이트를 포함한다.

도 8B는 경로 오버헤드의 구조를 도시하고, 도 8C는 페이로드(SPE/VC)에서 POH의 위치를 도시한다. 도 8B 및 도 8C에 도시된 바와 같이, POH는 SONET 및 SDH에 대해 각각 J1, B3, C2, G1, F2, H4, Z3, Z4, 및 Z5와 J1, B3, C2, G1, F2, H4, F3, K3, 및 N1을 포함하고, 9 바이트 POH는 페이로드에서 제1 열 (column)에 위치한다.

수신 SONET/SDH 처리

RX 디프레이머(27)는 수신 SONET/SDH 프로세서로 실시된다. 수신 SONET/SDH 프로세서는 STS 신호의 프레임화, 디스크램블 처리, B1 및 B2 모니터를 포함하는 TOH/SOH 모니터, AIS 검출, 포인터 처리, 및 POH 모니터를 제공한다. 수신 SONET/SDH 프로세서는 다음의 기능을 실행한다:

* SAPI에 따라 LAPS의 정보 필드를 식별하고 추출한다.

* SONET/SDH 역프레임화하여 [A1 A1 A2 A2] 바이트가 검출되고 프레임화에 사용된다. OOF 및 LOF 표시자 (단일 이벤트 및 제2 이벤트)를 제공한다.

* SONET/SDH 프레임 동기화 디스크램블러(29)를 사용하는 페이로드, 다항식 (X⁷+ X⁶+ 1)의 디스크램블 처리.

* 오버헤드 모니터 블록(32)에 의해 실행되는 오버헤드 모니터.

* 포인터 상태 결정 또는 해석 유닛(28)은 수신된 포인터의 상태 (Normal, LOP, AIS)를 정하도록 H1-H2 바이트를 조사한다. 포인터 상태가 정상이면, 제1 H1H2 바이트는 SPE/VC의 시작을 결정하도록 판독된다.

* POH 모니터 블록(31)은 J1, B3, C2, 및 G1 모니터로 구성된다. 이들 POH 바이트는 에러 또는 상태 변화에 대해 모니터된다.

* 수신된 신호의 비트 에러 비율이 2개의 다른 임시 한계값 이상 또는 이하인가 여부를 결정할 목적으로, IOSL은 2개의 B2 에러 비율 한계값 블록을 제공한다. 한계값이 인터럽트를 통해 능가될 때, SF (Signal Fail) 및 SD (Signal Degrade) 조건이 보고된다.

전송 SONET/SDH 처리

TX 프레이머(25)는 전송 SONET/SDH 프로세서로 실시된다. 전송 SONET/SDH 프로세서는 LAPS 프레임을 SPE/VC로 캡슐화한다. 이어서, 적절한 POH 및 TOH/SOH를 삽입하고, 광섬유 송수신기로 이어지는 병렬 대 직렬 변환기에 최종적인 STS 신호를 출력한다.

* SPE/VC (Synchronous Payload Envelope/Virtual Container) 포인터 조정 블록(24)은 포인터를 조정하고, SONET에 대한 SPE 또는 SDH에 대한 VC를 생성하도록 발생한 POH와 시스템 인터페이스로부터의 LAPS 프레임을 멀티플렉스 처리한다.

* 오버헤드 삽입 블록(33)에 의해 오버헤드::POH 바이트를 삽입한다.

* SONET/SDH 프레임 동기화 스크램블러(23)를 사용하는 페이로드, 다항식 (X⁷+ X⁶+ 1)의 스크램블 처리.

이후에는 LAPS 처리를 상세히 설명한다.

LAPS 처리

본 발명의 실시예에 따라, IOSL 프레이머/디프레이머(11)는 SPE (SONET Payload Envelop)로부터 프레임/패킷을 추출한다. 프레임/패킷은 LAPS 프로세서를 통해 추출된다. IOSL은 또한 SPE가 시스템 인터페이스에 직접 전해지도록 허용하는 통과 모드를 지지한다. LAPS 프로세서는 LLC 및 다른 패킷 근거의 데이터에 대해 LAPS와 같은 프레임화를 실행한다. LAPS 프로세서는 본 발명에 따라 패킷을 LAPS 프레임으로 캡슐화하는데 사용되는 단일 채널 엔진이다. LAPS 프로세서는 SONET/SDH에 대해 바이트 정렬 데이터에만 (예를 들면, 메시지는 정수 바이트 길이이다) 동작한다. 본 발명의 한 실시예에 따라, LAPS 프로세서는 도 7에 도시된 바와 같이, 수신 LAPS 프로세서 및 전송 LAPS 프로세서로 나뉜다.

캡슐화

LAPS 링크 엔터티는 조정 서브층 및 동일한 "POS PHY/UTOPIA"를 통해 네트워크층 또는 다른 상단층으로부터 프레임을 받아들인다. IP와 LAPS 및 SDH 사이의 적응 및 원선 관계는 도 3B, 도 3C, 및 도 5A, 도 5B에 도시된다. 도 4는 한 종류의 정보 필드를 캡슐화한 이후에 LAPS 프레임의 포맷을 나타낸다. SDH를 통한 IP의 기능 유닛은 들어오는 모든 LAPS 정보 필드를 원래 링크 포트를 제외한 피어 연결 링크에 전하고, 이들을 전달하기 이전에 하나 이상의 들어오는 프레임을 버퍼 처리하도록 허용된다.

수신 LAPS 프로세서

RX LAPS 프로세서(27)의 LAPS 수신(Rx) 처리는 주로 다음의 기능을 포함한다.

-- 수신된 SPE (Synchronous Payload Envelop) 옥텟 스트림은 하나 이상의 연속적인 LAPS 프레임 스트림을 포함하는 것으로 가정된다.

-- LAPS 캡슐화는 시작 플래그 시퀀스, 어드레스 필드(SAPI, Service Access Point Identifier), 제어 필드(0x03), 정보 필드(Ipv4, Ipv6, 또는 PPP 프로토콜 데이터 유닛), FCS(Frame check sequence), 및 종료 플래그 시퀀스로 구성된다.

-- Ipv4, Ipv6, IS-IS, 또는 PPP 프로토콜 데이터 유닛은 추출되어 Rx FIFO (First-In-First-Out)(20)에 저장된다.

수신 LAPS 프로세서(27)는 LAPS 프레임의 추출, 투명성 제거, FCS 에러 점검, SPC/VC 페이로드의 디스크램블 처리, 제어와 어드레스 필드의 선택적인 삭제, 및 성능 모니터를 제공한다.

필드 플래그의 시작/종료 및 바이트 스터핑 (stuffing)이 제거된 이후에, 나머지 페이로드는 데이터 및 FCS 필드를 포함한다. 상세한 내용은 이후 도면을 참고한다. 2개의 패킷 사이에서는 단 하나의 플래그 바이트만이 요구됨을 주목한다. 패킷 사이의 모든 플래그는 버려진다.

특별히, 수신 LAPS 프로세서는 다음의 기능을 실행한다:

* 수신된 페이로드(X⁴³+ 1 다항식)를 선택적으로 자체 동기화 디스크램블 처리한다.

* LAPS 프레임 (예를 들면, 프레임 범위 지정 플래그 검출)을 검출하여 종결짓는다.

* 제어 탈출 스터핑을 제거한다.

* 선택적인 FCS 코드(32 비트)를 계산하고, 이를 수신된 FCS 값과 비교한다. 에러는 성능 모니터 레지스터에 누적된다. 출력되는 데이터는 FCS 에러가 검출되는 경우 에러가 있는 것으로 표시된다.

* 바이트 스트림에서 (0x7D, 0x7E)에서 중지 순차를 검출한다.

* 어드레스 및 제어 필드를 선택적으로 삭제한다.

* 선택적인 최대 및 최소 패킷 길이 검출 (SW 구성가능한)을 제공하고, 데이터의 RX_ERR 신호가 에러 조건을 표시함을 주장한다.

* 옥텟에 대한 성능 모니터를 발생한다: FCS 에러, 중지 패킷, 단기 패킷, 장기 패킷, RXFIFO 에러로 인해 없어진 패킷.

* 종료부에서 떨어진 FIFO 언더플로그 (underflow) 조건을 처리하는데 사용되는 패킷 스터핑을 선택적으로 삭제한다.

* 에러 조건에 인터럽트를 발생한다.

* 플래그의 패킷간 갭을 자동적으로 선택한다.

이후에는 RX LAPS 프로세서(27)의 기능에 대해 상세한 실시를 설명한다.

LAPS 프레임 동기화

플래그 시퀀스(0x7E)는 LAPS 프레임의 시작/종료를 식별한다. 수신된 SPE 페이로드 데이터는 LAPS 프레임 경계에 위치하기 위해 플래그 순차에 대해 옥텟 별로 탐색된다. 플래그 순차를 식별하는데 사용되는 옥텟값은 프로그램가능하고 0x7E로 디폴트 (default)된다.

2개의 연속적인 플래그 순차는 간단히 무시되는 빈 프레임을 구성한다. 그러므로, N개의 연속적인 플래그 순차는 N-1개의 빈 프레임으로 카운트된다. 너무 짧은 프레임인 무효 프레임은 없애진다. LAPS 프레임이 다음과 같으면, 프레임을 무효인 것으로 생각된다.

a) 2개의 플래그로 적절하지 않게 경계지워지는 경우; 또는

b) 프레임의 플래그 사이에 6개 이하의 옥텟을 갖는 경우; 또는

c) 프레임 점검 순차 에러를 포함하는 경우; 또는

d) "4" (Ipv4 근거의 서비스), "6" (Ipv6 근거의 서비스), "255" (PPP 근거의 서비스)와 정합되지 않거나 수신기에 의해 지지되지 않는 서비스 억세스점 식별자를 포함하는 경우; 또한

e) 인식가능하지 않은 제어 필드값을 포함하는 경우; 또는

f) 6개 이상의 "1" 비트 시퀀스로 끝나는 경우.

LAPS 옥텟 디스터핑 (destuffing) 처리 (투명성 처리)

LAPS 옥텟 디스터핑 처리 (또한 때로 탈출 변환 (escaping transform)라 칭하여지는)는 FCS 계산 이전과 LAPS 프레임 동기화 이후에 수신된 LAPS 프레임에 적용된다. 옥텟 디스터핑은 제어 탈출 옥텟에 대한 시작 및 종료 플래그 순차 사이의 전체 LAPS 프레임을 조사함으로서 실행된다. 발견되면, 제어 탈출 옥텟은 옥텟 스트림으로부터 제거되고, 이어지는 옥텟은 옥텟 디스터핑 마스킹 옥텟과의 "XOR (exclusive-or)" 연산에 적용된다. 중지 시퀀스는 탈출 시퀀스로 생각되지 않는다.

제어 탈출 옥텟값은 프로그램가능하고 0x7D로 디폴트된다. 옥텟 디스터핑 마스킹 옥텟은 프로그램가능하고 0x20으로 디폴트된다. 한 예로, 0x7E는 0x7D, 0x5E로 부호화된다. 0x7D는 0x7D, 0x5D로 부호화된다.

SAPI 프로토콜 캡슐화 필드(어드레스 필드) 스트립핑 (stripping)

SAPI 필드는 LAPS 플래그에 이어서 옥텟 위치에 정해지도록 지정된다. SAPI 필드는 단일 옥텟 길이이다. 16진수값 "0x04", "0x06", "0x08", "0x0c", 및 "0xff"는 각각 Ipv4 근거의 패킷, Ipv6 근거의 패킷, IS-IS 근거의 패킷, 에테르넷 근거의 패킷, 및 PPP 근거의 패킷을 의미한다. SAPI 필드는 프레임이 RX FIFO(20)에 저장되기 이전에 스트립 처리된다.

LAPS 중지 시퀀스

중지 시퀀스(플래그 시퀀스로 이어지는 제어 탈출)는 들어오는 LAPS 프레임에서 선택적으로 검출될 수 있다. 중시 시퀀스는 중지되는 LAPS 프레임의 끝을 표시한다.

FCS 계산

수신된 FCS 필드가 확인된다. 옥텟 디스터핑 과정이 실행된 이후에, 플래그 시퀀스(FCS 필드를 포함하는)의 범위를 정하는 LAPS 시작/종료 사이의 전체 옥텟에 걸쳐 FCS 점검합 (checksum)이 계산된다. 2개의 다른 FCS 종류에 대해 검증이 실시될 수 있다.

첫번째는 발생기 다항식(generating polynomial) 1 + x⁵+ x¹²+ x¹⁶을 갖는 16-비트 CRC-CCITT이다. 16 비트 FCS에 대해 "양호한 최종 FCS" 값은 0xF0B8이다 (주: 16-비트 FCS는 RFC 2615와 호환가능하도록 LAPS의 SAPI가 "11111111"로 설정될 때 RFC 2625라 칭하여진다. 이 경우, FCS의 길이는 2개의 옥텟으로 변한다). 두번째는 발생기 다항식 1 + x + x²+ x⁴+ x⁵+ x⁷+ x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+ x²³+ x²⁶+ x³²를 갖는 32-비트 CRC-32 함수이다. 32-비트 FCS에 대해 "양호한 최종 FCS"는 0xDEBB20E3이다.

최하위 FCS 옥텟은 최종 LAPS 정보 필드 옥텟 직후에 위치하는 먼저 도착한 FCS 필드 옥텟이다. CRC 계산기에는 옥텟 당 먼저 최하위 (나중에 도착한) 비트가 공급된다. 계산된 FCS 점검합이 "양호한 최종 FCS값"과 정합되지 않으면, LAPS의 FCS는 에러가 있는 것으로 생각된다. 디폴트의 경우, FCS 검증은 32-비트 CRC에 대해 실행된다.

자체 동기화 스크램블러 (Self-Synchronizing Scrambler, SSS) 1 + x ⁴³ 의 디스크램블 처리

도 9B는 본 발명의 한 실시예에 따른 도 7의 디스크램블러(29)의 구조를 설명한다. 도 9B에 도시된 바와 같이, 디스크램블러는 XOR 게이트 및 43-비트 쉬프트 레지스터를 포함하고, 출력 비트는 스크램블 처리되지 않은 비트를 만들도록 입력된 스크램블 데이터와 XOR 처리된다.

수신된 데이터는 자체 동기화 디스크램블러 x⁴³+ 1로 디스크램블 처리된다. 도착 비트는 들어온 순서대로 디스크램블 처리된다. 디스크램블러는 3가지의 다른 방법 - 전체적인 디스크램블 처리, 부분적인 디스크램블 처리, 및 비-디스크램블 (non-descramble) 처리 -으로 동작될 수 있다. 3가지 다른 방법의 선택은 초기 구성에 의해 이루어진다. 전체적인 디스크램블 처리에서, SSS는 임의의 LAPS 프레임화 기능이 실행되기 이전에, 즉 SPE 페이로드의 전체적인 내용이 디스크램블 처리되기 이전에 적용된다. 부분적인 디스크램블 처리에서, SSS는 플래그 시퀀스 및 중지 탈출 옥텟을 제외한 모든 LAPS 옥텟에 적용된다. 부분적인 스크램블러는 옥텟 디스터핑 이전, LAPS 프로토콜 필드 처리 이후에 적용된다. 디스크램블 처리과정은 모두 독립적으로 on/off 될 수 있다. 비-디스크램블 처리는 스크램블 기능을 디스에이블 (disable)시키는 것이다. 이는 스크램블러 기능이 부가되지 않은 구형 장비와의 상호동작성에 중요하다. 디폴트의 경우에서는 전체적인 디스크램블 처리과정이 on (인에이블 (enable)) 상태로만 설정된다.

너무 긴 패킷 처리

Rx FIFO에 기록된 전체 패킷의 옥텟 수가 최대 패킷 크기 (Maximum Packet Size, MPS)의 프로그램가능한 값 보다 더 크면, 패킷은 "너무 긴" 것으로 생각된다.

너무 긴 패킷에 대해서는 MPS 이상의 패킷을 Rx FIFO에 기록할 수 없다. Rx FIFO에 기록되는 긴 패킷 중 최종 워드(word) (SDH/SONET 주요 비율 STM-1/4/16/64 또는 OC-3/12/48/192에서, 네트워크 프로세서에 대해 가능한 인터페이스 구성/입력 폭은 8bit x 25Mhz, 16bit x 50Mhz, 32bit x 100Mhz, 64bit x 50Mhz, 64bit x 200Mhz, 12bit x 100Mhz이다)는 이 기능이 인에이블 또는 디스에이블 상태인가 여부에 관계없이 항상 EOP 표시된다. 또한, Rx FIFO 에러 표시 동작 및 해고 (discard) 기능은 이 기능과 무관한다. 이 옵션은 Rx FIFO 에러 표시 및 Rx FIFO 해고 기능 모두가 인에이블 상태인 경우에만 사용되어야 함을 주목한다. Ipv4의 MPS는 1600 옥텟으로 디폴트되고, Ipv6의 MPS로 변화 및 프로그램될 수 있다. 디폴트의 경우, 긴 패킷 중 MPS만이 Rx FIFO에 기록된다.

너무 짧은 패킷 처리

Rx FIFO에 기록되는 전체 패킷의 옥텟 수가 프로그램가능한 값의 최소 패킷 크기(Minimum Packet Size, mPS) 보다 작으면, 패킷은 "너무 짧은" 것으로 생각된다.

mPS는 64 옥텟으로 디폴트되고, 8 내지 65535의 범위내에서 프로그램될 수 있다.

Rx FIFO에서 SAPI 및 정보 필드 저장

SAPI 및 정보 필드는 LAP 프레임 당 STM-64c/OC-192c에 대해 128-비트 또는 64-비트 경계, STM-16c/OC-48c에 대해 64-비트 또는 32-비트 경계, STM-4c/OC-12c에 대해 16-비트 경계, STM-1/OC-3c에 대해 8-비트 경계로 정렬되어 Rx FIFO에 추출 및 저장된다. Rx FIFO의 SAPI 필드 저장은 인에이블/디스에이블될 수 있다. 디폴트에 의해, SAPI 필드는 Rx FIFO에 저장된다. 예를 들어, Rx FIFO 크기는 OC-48c/STM-16c에서 512 워드(32 x 100Mhz)이므로, 총 2048 정보 필드 옥텟의 저장을 수용할 수 있다. 1600 옥텟의 MPS를 가정하면, 이는 한 패킷 + 일부 추가 오버헤드(약 448 옥텟)에 대한 버퍼 풀 (buffer pool)을 수용한다. 한 워드는 매 77.8MHz 코어 클럭 싸이클 마다 Rx FIFO에 기록될 수 있다. 수신된 정보 필드는 그들 사이에 최소 5 옥텟의 공간을 둔다 (4개 FCS 옥텟 + 1개 플래그 시퀀스 옥텟). 4개 SPE 페이로드 옥텟은 매 77.8MHz 코어 클럭 싸이클 마다 도착하고, 한개의 워드는 매 77.8MHz 코어 클럭 싸이클 마다 Rx FIFO에 기록될 수 있다. 그러므로, 임의의 SAPI/정보 필드 크기에 대해, Rx FIFO 기록 인터페이스에는 SAPI/정보 필드를 저장하기에 충분한 대역폭이 있게 된다. 그래서, Rx FIFO 기록 인터페이스에는 LAPS 페이로드 스트림의 수신을 처리하는데 충분한 대역폭이 있다.

Rx FIFO 오버플로우 이벤트 처리

SDH/SONET 프레이머를 통한 IP는 기록 방향에서 Rx FIFO에 패킷을 기록한다. Rx FIFO가 가득차게 되면 (Rx FIFO 슬롯의 최종 이용가능한 워드가 채워지면), 관리 인터페이스에 오버플로우 이벤트를 보고하도록 알람이 발생된다. FIFO 오버플로우의 발생은 또한 성능 카운터가 실시될 수 있게 한다. 이 경우, Rx FIFO에 저장된 최종 워드의 EOP 필드는 논리 1 값으로 자동 설정된다.

Rx FIFO가 가득차는 이벤트를 겪은 패킷에서, 나머지 패킷 옥텟은 (있는 경우) Rx FIFO에 저장되지 않는다. 더욱이, 프로그램가능한 초기 레벨의 자유 저장 영역에 이를 때까지 Rx FIFO에는 워드가 기록되지 않는다. 가득차는 이벤트에 이어서 Rx FIFO에 기록되는 제1 워드는 SOP 표시 워드가 된다.

에러 처리:

다수의 이벤트는 수신된 LAPS 프레임에 "에러가 있는" 것으로 정의한다. 에러가 있는 LAPS 프레임에는 2가지의 다른 과정이 적용될 수 있다:

(1) 에러 표시. SDH/SONET 프레이머를 통한 IP는 Rx FIFO 오버플로우에 의해 변형된 에러 패킷을 마스크한다. 대응하는 LAPS 에러 프레임에 대해 Rx FIFO에 기록된 최종 SAPI/정보 필드 워드에서는 Rx_ERR 플래그가 설정된다.

(2) 패킷 해고. 대응하는 LAPS 에러 프레임에 대해 Rx FIFO에 기록된 모든 SAPI/정보 필드 워드(패킷)은 버려진다.

연결 관리 기능

도 7에 도시된 바와 같이, IOSL 프레이머/디프레이머는 데이터 전송 동안 에러 또는 분리를 결정하는 연결 관리 유닛(36)을 포함한다. 연결 관리 엔터티(36)는 선택적으로 피어 링크 프레임을 수신하는 링크 상태를 모니터하는데 사용된다. 이는 단지 국부적인 문제이고, RX측과 TX측 사이에서 사용되는 연관 프레임을 갖지 않는다.

특별히, 연결 관리 유닛(36)은 타이머(T200) 및 카운터(N200)를 포함한다.

-- 초기화 이후 (T200 및 N200의 디폴트가 각각 1 내지 3초로 설정된 이후), 링크 엔터티는 정상적인 전송기 및 수신기 통로로 들어간다.

-- 프레임 (정보 프레임 및 프레임간을 채우는 시간을 포함하는)이 수신되기 이전에 타이머 T200이 만기되면, 링크 엔터티는 타이머 T200를 재시작하고, 재전송 카운터 N200를 감소시킨다.

-- 프레임이 수신되기 이전에 타이머 T200이 만기되고 재전송 카운터 N200이 0으로 감소되면, 링크 엔터티는 MDL-ERROR 표시 원선을 통해 로컬 연결 관리 엔터티에 이를 알리고, 타이머 T200를 재시작하고 N200의 값을 회복한다.

-- T200 및 N200의 값은 구성가능하다. T200 및 N200으로 구성된 최소 유닛은 각각 100 msec 및 1이다.

다음 통계는 성능 모니터 카운터에서 이용가능해진다. 모든 성능 모니터 카운터는 32-비트의 길이이다.

* 수신된 빈 LAPS 프레임

* 수신된 너무 긴 패킷

* 수신된 무효 프레임

이후에는 TX LAPS 프로세서의 처리를 상세히 설명한다.

전송 LAPS 프로세서

TX LAPS 프로세서(22)의 LAPS 전송(Tx) 처리는 주로 다음의 기능을 포함한다:

-- TX FIFO(18)로부터 판독되고 LAPS 프레임으로 캡슐화된 Ipv4, Ipv6, 또는 PPP 프로토콜 데이터 유닛은 SPE 페이로드로의 맵핑 요구조건에 만족된다.

-- LAPS 캡슐화는 시작 플래그 시퀀스, 어드레스 필드(SAPI, Service Access Point Identifier), 제어 필드(0x03), 정보 필드(Ipv4, Ipv6, 또는 PPP 프로토콜 데이터 유닛), FCS(Frame check sequence) 필드, 및 종료 플래그 시퀀스로 구성된다.

-- 전송된 SPE (Synchronous Payload Envelop) 옥텟 스트림은 하나 이상의 연속적인 LAPS 프레임 스트림을 포함하는 것으로 가정된다.

특별히, 전송 LAPS 프로세서(22)는 패킷 근거의 정보를 STS SPE로 삽입한다. 이는 패킷 캡슐화, FCS 필드 발생, 패킷 사이를 채우는 것, TX FIFO 에러 회복, 및 스크램블 처리를 제공한다. 전송 LAPS 프로세서는 다음의 기능을 실행한다:

* LAPS 프레임내의 패킷을 캡슐화한다. 각 패킷은 시작 플래그(0x7E), 선택적인 FCS 필드, 선택적인 어드레스와 제어 필드, 및 필드 플래그의 선택적인 종료(0x7E)로 캡슐화된다.

* 선택적인 자체 동기화 전송 페이로드 스크램블러 (X43 + 1 다항식).

* ITU-T X.85에 의해 요구되는 투명성 처리 (플래그 및 제어 탈출을 위한 옥텟 스터핑). 바이트 스터핑은 필드 플래그의 시작과 종료 사이에 일어난다. 스터핑은 플래그 또는 제어 탈출 바이트와 정합되는 바이트를 (0x20)HEX와 XOR 처리된 원래 바이트로 이어지는 제어 탈출로 구성된 2 바이트 시퀀스와 대치한다.

* 필드 플래그(0x7E)의 시작 및 종료를 발생한다. 단일 플래그는 두 패킷사이에서 공유될 수 있음을 주목한다.

* 선택적으로 프레임 점검 시퀀스(Frame Check Sequence) 필드에 대해 32-비트 CRC를 발생한다.

* SW 제어하의 테스트를 위해 FCS 에러를 삽입하는 기능을 제공한다.

* TX_PRTY 에러가 인터럽트를 발생한다.

* FIFO 언더플로우의 선택가능한 처리를 제공한다. FIFO 언더플로우 조건은 패킷의 종료 이전에 TX FIFO가 비워있을 때 일어난다. 이 경우, 인터럽트가 발생된다. 패킷은 FCS 에러나 중지 시퀀스의 발생을 통해 종료되거나, SW 구성가능 탈출 코드를 통해 갭 (gap) 동안에 "채우는 (fill)" 바이트가 삽입될 수 있다.

* 다음을 포함하는 성능 모니터 카운트를 발생한다: FIFO 에러 이벤트의 수, 중지된 패킷, 또한 최소 및 최대 패킷 길이 매개변수를 위반하는 패킷의 수 (SW 구성가능).

LAPS 프레임 캡슐화

데이터 링크층에서의 각 프레임은 본 발명에 따라 플래그 시퀀스를 사용하여 서술된다. 플래그는 LAPS 프레임의 시작 및 종료를 모두 나타내는데 사용된다. LAPS 프레임 옥텟 스트림은 또한 비율 적응의 필요에 따라 LAPS 프레임 사이에 플래그 시퀀스를 삽입함으로서 SPE 페이로드 대역폭에 적응된다. 전송된 LAPS 프레임은 적어도 하나의 플래그 시퀀스에 의해 분리된다. 삽입된 플래그 시퀀스 옥텟값은 프로그램가능하고, 0x7E로 디폴트된다. 이전 프레임의 종료 플래그는 다음 프레임의 시작 플래그가 될 수 있다.

LAPS 어드레스 필드(또는 SAPI)는 시작 플래그 시퀀스 이후에 삽입된다. 삽입된 어드레스 필드값은 프로그램가능하고, 캡슐화된 패킷 종류에 의존한다. SAPI는 들어오는 데이터 패킷의 종류에 의존하여 결정 유닛에 의해 결정된다. Ipv4 근거의 패킷, Ipv6 근거의 패킷, IS-IS 근거의 패킷, 에테르넷 근거의 패킷, 및 PPP 근거의 패킷에 대해, 대응하는 값은 각각 "0x04", "0x06", "0x08", "0x0C", 및 "0xFF"이다.

LAPS 제어 필드는 어드레스 필드에 이어진다. 삽입된 제어 필드값은 설정되고, 0x03으로 디폴트된다.

LAPS FCS(Frame Check Sequence)는 어드레스, 제어, 프로토콜, 및 정보 필드에 걸쳐 계산된다. 이는 플래그 시퀀스 또는 FCS 필드 자체를 포함하지 않는다. 계산은 옥텟 스터핑이 적용되기 이전에 실행되다. 2종류의 FCS 종류가 발생될 수 있다. 첫번째는 발생기 다항식 1 + x⁵+ x¹²+ x¹⁶을 갖는 16-비트 CRC 함수이다. (주: 16-비트 FCS는 RFC 2615와 호환가능하도록 LAPS의 SAPI가 "11111111"로 설정될 때 RFC 2625라 칭하여진다. 이 경우, FCS의 길이는 2개의 옥텟으로 변한다). 두번째는 발생기 다항식 1 + x + x²+ x⁴+ x⁵+ x⁷+ x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+ x²³+ x²⁶+ x³²를 갖는 32-비트 CRC-32 함수이다.

IOSL 프레이머/디프레이머(11)는 CRC-32 FCS 발생 및 점검을 지지한다. FCS에서는 먼저 최상위 항의 계수를 포함하는 최하위 옥텟이 전송된다. IOSL 디바이스는 LAPS에 대해 작은 엔디언 (endian) 비트 순서 또는 큰 엔디언 비트 순서를 사용하여 FCS를 계산하도록 제공될 수 있다.

FCS 필드는 투명성을 위해 삽입된 옥텟을 포함하지 않고 어드레스(SAPI 값), 제어, 정보 필드의 모든 비트에 걸쳐 계산된다. 이는 플래그 시퀀스나 FCS 필드 자체를 포함하지 않는다. 두가지 FCS 방법에서, CRC 발생기 및 점검기는 모두 논리 "1" 값으로 초기화된다. FCS 계산이 완료되면, FCS 값은 1의 보수이다. 이것은 FCS 필드에 삽입되는 새로운 값이다.

계산된 FCS는 16-비트 및 32-비트 FCS에 대해 각각 0xFFFF 또는 0xFFFFFFFF와 계산된 FCS값을 XOR 처리함으로서 LAPS 프레임에 삽입되기 이전에 보수화된다. 최하위 FCS 옥텟(최상의 항의 계수)은 최종 정보 필드 옥텟 직후에 위치하는 먼저 삽입/전송된 FCS 옥텟이다. CRC 계산기에는 옥텟 당 먼저 최하위 (마지막으로 전송된) 비트가 공급된다. 디폴트의 경우, 32-비트 FCS 값이 삽입된다.

옥텟 스터핑

LAPS 옥텟 스터핑 과정 (또한 때로 탈출 변환이라 칭하여지는)은 FCS 계산 및 부분적인 스크램블 처리 이후 전송된 LAPS 프레임에 적용된다. 옥텟 스터핑은 제어 탈출 옥텟에 대해 시작 및 종료 플래그 시퀀스 사이에서 전체 LAPS 프레임을 조사함으로서 실행된다. 발견될 때, 0x7E는 0x7D, 0x5E로 부호화된다. 0x7D는 0x7D, 0x5D로 부호화된다. 중지 시퀀스는 탈출 시퀀스로 생각되지 않는다.

제어 탈출 옥텟값은 프로그램가능하고, 0x7D로 디폴트된다. 옥텟을 마스크하는 옥텟 스터핑은 프로그램가능하고, 0x20으로 디폴트된다.

자체 동기화 스크램블러 (SSS) X ⁴³ + 1의 스크램블 처리

도 9A는 본 발명의 한 실시예에 따른 도 7의 스크램블러(23)의 구조를 설명한다. 도 9A에 도시된 바와 같이, 스크램블러(23)는 XOR 게이트 및 43-비트 쉬프트 레지스터를 포함하고, 출력 비트는 스크램블 처리된 비트를 만들도록 생 (raw) 입력 데이터 비트와 XOR 처리된다.

전송된 데이터는 자체 동기화 스크램블러 X⁴³+ 1로 스크램블 처리된다. 전송된 비트는 전송된 순서대로 스크램블 처리된다. 스크램블러는 3가지 다른 방법 - 전체적인 스크램블 처리, 부분적인 스크램블 처리, 및 비-스크램블 처리 -으로 동작될 수 있다. 3가지 다른 방법의 선택은 초기 구성으로 이루어진다. 전체적인 스크램블 처리에서, SSS는 SPE로 맵핑되기 이전에, SPE 페이로드의 전체 내용이 스크램블 처리되기 이전에 적용된다. 부분적인 디스크램블 처리에서, SSS는 플래그 시퀀스 및 중지 탈출 옥텟을 제외한 모든 LAPS 옥텟에 적용된다. 부분적인 스크램블러는 PPP/LAPS 필드 발생 이후, 스터핑 처리 이전에 적용된다. 스크램블 처리과정은 모두 독립적으로 on/off 상태로 될 수 있다. 비-디스크램블 처리에서, 이는 스크램블 처리 기능을 디스에이블시키는 것이다. 이는 스크램블러 기능이 부가되지 않은 구형 장비와의 상호동작성에 중요하다. 디폴트의 경우, 전체적인 스크램블 과정만이 on (인에이블) 상태로 설정된다.

SAPI 및 정보 필드

SAPI 및 정보 필드는 LAPS 프레임 당 STM-64c/OC-192c에 대해 128-비트 또는64-비트 경계, STM-16c/OC-48c에 대해 64-비트 또는 32-비트 경계, STM-4c/OC-12c에 대해 16-비트 경계, STM-1/OC-3c에 대해 8-비트 경계로 정렬되어 Tx FIFO에서 얻어지거나 내부적으로 발생된다. 내부적으로 발생될 때, 삽입된 SAPI 필드의 크기 (1 또는 2 옥텟) 및 값은 프로그램가능하고, 단일 옥텟값 0x04 (Ipv4 근거의 서비스를 의미하는)로 디폴트된다. Tx FIFO로부터 얻어질 때, Tx FIFO에 저장된 패킷은 발생된 LAPS 프레임에서 SAPI/정보 필드로 삽입된다. 디폴트의 경우, SAPI 필드 소스는 Tx FIFO이다.

패킷은 LAPS 프레임 당 STM-64c/OC-192c에 대해 128-비트 또는 64-비트 경계, STM-16c/OC-48c에 대해 64-비트 또는 32-비트 경계, STM-4c/OC-12c에 대해 16-비트 경계, STM-1/OC-3c에 대해 8-비트 경계로 정렬된다. Tx FIFO의 크기는 1 내지 4096 워드의 범위에서 프로그램가능하고, 여기서 한 워드는 32 비트와 같다. 디폴트의 경우, 크기는 4096 워드로, 이는 16384 옥텟의 패키지 데이터 저장과 동일하다.

Tx FIFO에 저장된 모든 유효한 패킷 옥텟은 판독되어 발생된 LAPS 프레임의 SAPI/정보 필드에 맵핑된다. 데이터는 SPE에 LAPS 프레임을 연속 맵핑하는 방식으로 Tx FIFO로부터 판독된다. 패킷 전달 모드에서, 패킷의 판독은 Tx FIFO에 적어도 하나의 EOP (End of Packet) 표시 워드가 있을 때까지 시작되지 않는다. 워드 전달 모드에서, Tx FIFO로부터의 패킷 판독은 전체 패킷이 Tx FIFO에 저장되지 않을 때도 시작될 수 있다. 디폴트 모드에서는 워드 전달 모드가 인에이블된다.

Tx FIFO 언더플로우 처리

Tx FIFO로부터 패킷을 판독하는 동안, EOP 패킷 표시 워드가 판독되기 이전에 기대되지 않은 빈 방식으로 Tx FIFO가 운행되면, 이 패킷이 맵핑되어 있는 LAPS 프레임은 선택적으로 LAPS 중지 시퀀스로 중지될 수 있다. CPU 인터페이스를 통해 이루어진 LAPS 중지 요구는 다음 프레임이 Tx FIFO 언더플로우 때문에 버려지는 경우 활성화된다.

선택적인 중지 옵션이 off로 설정되면, 전송된 LAPS 프레임은 계산된 FCS 필드로 종료된다. 언더플로우가 일어났을 때 Tx FIFO로부터 판독된 패킷의 나머지는 플러쉬 (flush) 처리된다. 이는 SOP 표시 워드가 발견될 때까지 Tx FIFO로부터 판독함으로서 행해진다. 그 동안에는 빈 프레임이 전송된다.

중지 프레임

프레임이 중지되었음을 나타내는데는 특수한 바이트 코드(0x7D 0x7E)가 사용된다. 이들 바이트가 수신되면, 연관된 프레임은 버려진다. 패킷이 피어 링크 서비스로 전송되면, 이는 에러가 있는 것으로 표시된다.

이후에는 본 발명의 한 실시예에 따라 프레이머/디프레이머에서 전송 방향의 데이터 처리를 상세히 설명한다.

전송 방향에서, IOSL 디바이스는 패킷 근거의 데이터를 STS/STM SPE에 삽입한다. 디바이스의 동작 모드는 관리 제어 인터페이스를 통해 제공될 수 있다.

전송 FIFO 인터페이스

IOSL 디바이스에서, 전송 시스템 인터페이스는 "POS PHY/UTOPIA"를 따른 인터페이스로 동작한다.

- 전송 FIFO

전송 시스템 인터페이스는 전송 경로의 전송 방향으로 IOSL 디바이스를 진행시키는 링크층 디바이스에 의해 제어된다. 링크층 디바이스는 모든 인터페이스 전달을 동기화하도록 IOSL 디바이스에 인터페이스 클럭을 제공한다. 이는 IOSL 디바이스가 비율-정합 버퍼 (즉, FIFO)를 포함하도록 요구한다. FIFO의 크기는 256 옥텟이다.

IOSL 디바이스는 또한 FIFO를 통해 패킷 상태 (패킷/셀의 시작/종료, 패킷에서 최종 워드가 1 또는 2 옥텟으로 구성되는가 여부, 패킷 에러)를 전달한다.

-- 전송 FIFO 에러

IOSL 디바이스에서, FIFO의 상태는 IOSL 디바이스에 의해 모니터된다. FIFO 에러 조건은 1) IOS_TX_SOP이 패킷 종료 (TX_EOP 표시) 이전에 수신될 때마다, 또한 2) TX_CLAV 신호의 주장에 이어서 "전송 윈도우 (transmit window)"의 범위를 넘어 IOS_TX_ENB가 활성화될 때마다 선언된다. FIFO 에러 이벤트는 IOS_TX_FIFOERR_E = 1로 설정함으로서 관리 인터페이스에 보고된다. IOSL 디바이스는 FIFO 에러 이벤트에 의해 영향을 받는 모든 패킷을 카운트하는 8-비트 FIFO 에러 카운터를 포함한다. 성능 모니터 카운터가 래치 (latch)될 때, 이 카운터의 값은 IOS_TX_FIFOERR_CNT[7:0] 레지스터로 래치되고, FIFO 에러 카운터는 클리어 (clear)된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 FIFO 에러 이벤트가 있으면, FIFO 에러 이벤트 비트 IOS_TX_FIFOERR_SECE가 설정된다. IOS 모드(IOS_TX_IOS = 1)에서, IOSL 디바이스는 에러가 있는 패킷을 중지시킨다.

- IOS 에러 패킷 처리

IOS 동작 모드(IOS_TX_IOS = 1)에서는 다음의 에러 패킷 처리 과정이 제공된다:

-- TX_ERR 링크층 표시

전송 시스템 인터페이스는 특정한 패킷이 에러를 포함하여 중지되거나 버려져야 할 때 링크층 디바이스가 IOSL 디바이스에 나타낼 수 있는 방법을 제공한다 (IOS_TX_ERR의 정의를 참고).

IOSL 디바이스는 에러가 있는 것으로 표시된 링크층으로부터 수신된 모든 패킷을 카운트하는 8-비트 링크층 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이될 때), 이 카운터의 값은 IOS_TX_IOS_LLPKT_ERRCNT[7:0] 레지스터로 래치되고, 링크층 패킷 에러 카운터는 클리어된다.

LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 링크층 패킷 에러가 있으면, 링크층 패킷 에러 이벤트 비트, IOS_TX_IOS_IIPKT_ERR_SECE가 설정된다.

-- 최대/최소 패킷 크기

IOSL 디바이스는 또한 한 옵션으로 에러가 있는 패킷을 관찰하고, 이것이 최소 또는 최대 패킷 크기를 위반하면 이를 전송하지 않거나 중지시킨다. 패킷 크기는 LAPS 패킷만의 크기를 칭하고, IOSL 디바이스에 의해 삽입된 바이트 (플래그 시퀀스, 어드레스, 제어, FIFO 언더플로우, 투명성, 또는 FCS 바이트)를 포함하지 않는다.

최소 및 최대 크기는 관리 제어 인터페이스를 통해 프로그램가능하다. IOS 디바이스에는 상기의 mPS, MPS와 같이 다양한 값을 저장하는 다수의 레지스터가 있다.

- 라인측 패킷 루프백

테스트를 위해, IOSL 디바이스는 또한 사용자가 SONET/SDH 신호로부터 추출하는 패킷을 전송 방향 FIFO에 루프백 (loopback)하는 기능을 제공하고, 여기서 이는 시스템 인터페이스로부터 수신된 데이터를 대신한다. 이 데이터에는 이어서 전송측 LAPS 처리가 실행되고, SONET/SDH 라인으로 다시 전달된다. IOS_R_TO_T_LOOP가 1로 설정될 때, 루프백이 활성화된다. IOS_R_TO_T_LOOP가 0일 때, 루프백은 금지되고 정상적인 처리가 진행된다.

이 루프백은 주로 디바이스 테스트를 위해 제공된다. 실제 동작에서, 수신 클럭이 전송 클록 보다 빠르고 SONET/SDH 페이로드가 패킷으로 채워지면, 전송측이 수신측의 전 데이터 비율을 수용할 수 없기 때문에 주기적으로 에러가 주어질 수 있다.

한 옵션으로, IOSL 디바이스는 한 프레임의 종료 및 다음 프레임의 시작 모두를 나타내는 단일 플래그를 삽입할 수 있다. 이는 관리 인터페이스를 통해 제어된다; IOS_TX_IOS_EOP_FLAG = 1이면, IOSL 디바이스는 프레임의 시작 및 종료를 나타내도록 분리된 플래그를 삽입한다. IOS_TX_IOS_EOP_FLAG = 0 (디폴트)이면, 단일 플래그 시퀀스만이 삽입될 수 있다.

FCS 필드의 발생이 금지되는 특수한 경우, IOS_TX_IOS_EOP_FLAG는 IOSL 디바이스에 의해 무시되고, 프레임 플래그 시퀀스의 시작 및 종료는 항상 삽입된다. 이는 FCS 필드가 ITU-T X.85에 따라 필수적이므로 비표준 동작이다. 이 특성은 FCS가 금지되고 단일 바이트 패킷이 가능한 테스트 주기 동안 수신측에서 적절한 동작을 보장하는데 요구된다.

-- 어드레스 및 제어 필드

프레임 플래그 시퀀스의 시작에 바로 이어서 2개의 필드가 있다: "0x0c"로 설정된 어드레스 바이트 및 00000011로 정의된 제어 바이트. IOS 모드(IOS_TR_IOS = 1)에서, IOS_TX_IOS_ADRCTL_INS = 1이면, IOSL 디바이스는 선택적으로 이들 필드를 삽입한다. IOS_TX_IOS_ADRCTL_INS = 0 (디폴트)이면, 이들 필드를 삽입하지 않는다.

-- 투명성

옥텟 스터핑 과정은 투명성 처리라 칭하여지는 지점에서 실행된다. 특정한 옥텟, 제어 탈출 (01111101 또는 16진수 0x7d)은 수신측에서 특정한 처리를 요구하는 바이트를 나타내는 표시자로 사용된다. 제어 탈출은 프레임 데이터에서 특정한 코드의 발생을 표시하는데 사용된다.

FCS 계산 이후에, IOSL 디바이스는 2개의 플래그 시퀀스 사이의 전체 프레임을 조사한다. 0x7e 또는 0x7d로 식별되는 임의의 코드의 각 발생은 16진수 0x20과 XOR된 원래 옥텟으로 이어지는 제어 탈출 옥텟으로 구성된 2개의 옥텟 시퀀스로 대치된다. IOSL 디바이스는 이어지는 바이트 시퀀스에서 투명성 처리를 실행하고, IOSL 디바이스에 의해 삽입된 플래그 시퀀스 중 하나를 제외하고 프레임을 서술한다. 페이로드에서 (플래그 시퀀스 사이) 0x7e가 발생되면, 다음에 기술된 바와 같이 처리된다:

0x7e는 0x7d, 0x5e로 부호화된다.

0x7d는 0x7d, 0x5d로 부호화된다.

SPE 발생

IOS 스트림은 SONET/SDH SPE (Synchronous Payload Envelope)의 페이로드로 맵핑된다. IOS 옥텟 경계는 SPE 옥텟 경계와 정렬된다. IOS 프레임이 가변 길이이므로, 이들은 SPE 경계를 가로지르도록 허용된다. 동작 동안, SPE로 즉시 삽입되는데 이용가능한 LAPS 프레임이 없을 때, 플래그 시퀀스는 LAPS 프레임 사이의 시간을 채우도록 전송된다. 이는 완전한 프레임 사이에서만 실행된다.

SPE/VC 발생

- SPE/VC 구조

SPE/VC의 제1 컬럼은 POH이다. 이들 9 바이트의 순서는 도 8A 내지 도 8C에 도시된 바와 같이 SONET 및 SDH에 대해 이후 도시된다.

참고로, SDH 가상 컨테이너의 대역폭 및 STM 인터페이스 비율이 각각 표 2 및 표 3에 도시된다.

SDH 가상 컨테이너의 대역폭
VC 종류	VC 대역폭 (kbit/s)	VC 페이로드 (kbit/s)
VC-11	1 664	1 600
VC-12	2 240	2 176
VC-2	6 848	6 784
VC-3	48 960	48 384
VC-4	150 336	149 760
VC-4-4c	601 304	599 040
VC-4-16c	2 405 376	2 396 160
VC-4-64v	9 621 504	9 584 640

STM 인터페이스 비율
STM 종류	STM 비트 비율 (kbit/s)
sSTM-11	2 880
sSTM-12	5 184
sSTM-14	9 792
sSTM-18	19 792
sSTM-116	37 444
sSTM-21	7 488
sSTM-22	14 400
sSTM-24	28 224
STM-0	51 840
STM-1	155 052
STM-4	622 080
STM-16	2 488 320
STM-64	9 953 280

SONET 전송 비율은 STS-1 (51.840Mbps)의 정수배이다. 허용된 배수는 기존에 다음과 같다:

STS-1: 51.840Mbps

STS-3: 155.520Mbps

STS-9: 466.560Mbps

STS-12: 622.080Mbps

STS-18: 933.120Mbps

STS-24: 1244.160Mbps

STS-36: 1866.240Mbps

STS-48: 2488.320Mbps

STS-192: 9 953 280 Mbps

- POH

9 바이트의 경로 오버헤드가 있다. 경로 바이트 중 제1 경로는 경로 트레이스(path trace) 바이트 J1이다. SONET/SDH TOH/SOH에 대한 위치는 연관된 STS/AU 포인터로 나타내진다. 이어지는 섹션은 POH 바이트의 전송값을 정의한다. 바이트명이 SONET과 SDH 사이에서 서로 다른 경우, SONET명이 먼저 리스트된다.

-- 경로 트레이스(J1)

IOSL 디바이스는 16-바이트 또는 64-바이트 경로 트레이스 메시지를 J1 바이트로 전송하도록 제공될 수 있다. 메시지는 IOS_TX_J1_[63:0]_[7:0]에 저장된다. IOS_TX_J1SEL = 0이면, J1 바이트는 IOS_TX_J1_[15]_[7:0] 내지 IOS_TX_J1_[0]_[7:0]에서 16-바이트 시퀀스로 반복하여 전송된다. 그렇지 않으면, IOS_TX_J1_[63]_[7:0] 내지 IOS_TX_J1_[0]_[7:0]의 64-바이트 시퀀스가 전송된다. (16-바이트 시퀀스는 일반적으로 SDH 모드에서 사용되고, 64-바이트 시퀀스는 SONET 모드에서 사용된다.)

-- 경로 BIP-8 (B3)

비트 인터리브 패리티 (Bit interleaved parity) 8 (BIP-8)은 B3_INV = 0인 경우 짝수 패리티 (정상)로 전송된다. 그렇지 않으면, 홀수 패리티 (부정확)가 발생된다. BIP-8은 이전 SPE/VC (POH를 포함하여)의 전체 비트에 걸쳐 계산되고, 현재 SPE/VC의 B3 바이트로 배치된다.

BIP-8의 정의에 의해, B3의 제1 비트는 이전 SPE/VC의 모든 바이트 중 제1 비트를 통해 패리티를 제공하고, B3의 제2 비트는 이전 SPE/VC의 모든 바이트 중 제2 비트를 통해 패리티를 제공한다.

-- 신호 라벨 (C2)

신호 라벨 바이트는 SPE/VC의 구성을 나타낸다. 제공된 값, TX_C2_[7:0]은 발생된 C2 바이트로 삽입된다.

-- 경로 상태 (G1)

경로 REI. 수신측은 수신된 SPE/VC에서 B3 비트 에러를 모니터한다. 각 프레임에서 에러 검출된 B3의 수 (0 내지 8)는 원격 에러 표시로 전송 경로 상태 바이트 G1에 삽입되도록 수신측에서 전송측으로 전달된다.

FORCE_G1ERR = 1이면, G1의 4 MSB는 1000으로 연속하여 전송된다 (테스트를 위해). PREI_INH = 0이면, 이는 수신측 POH 모니터 블록에 의해 가장 최근에 검출된 B3 에러의 수와 똑같은 이진수값 (0 내지 8을 나타내는 0000 내지 1000)으로 설정된다. 그렇지 않으면, 이는 모드 0으로 설정된다.

경로 RDI. G1의 비트 5는 경로/AU 원격 결함 표시 (Remote Defect Indication, RDI-P)로 사용되거나, G1의 비트 5, 6, 및 7이 진보된 RDI-P 표시자로 사용될 수 있다. G1의 비트 5, 6, 및 7로 전송된 값은 TX_G1_[2:0] 레지스터로부터 취해지거나 (PRDI_AUTO = 0인 경우), IOSL 디바이스가 자동적으로 진보된 RDI 신호 (PRDI_AUTO = 1 및 PRDI_ENH = 1인 경우), 또는 1 비트 RDI 신호 (PRDI_AUTO= 1 및 PRDI_ENH = 0인 경우)를 발생한다. G1의 비트 5, 6, 및 7로 전송되는 값은 표 4에 도시된다.

경로 RDI 비트값
PRDI-AUTO	PRDI-ENH	RX-PAISRX-LOP	RX-UNEQ	RX-PLM	G1 비트 5, 6,및 7
0	x	X	x	x	Tx_G1[2,0]
1	0	1	x	x	100
	0	0	x	x	000
	1	1	x	x	101
		0	1	x	110
		0	0	1	010
		0	0	0	001

PRDI_AUTO = 1이면, 상기에 도시된 값은 최소 20 프레임 동안 전송된다. 일단 20개 프레임이 똑같은 값으로 전송되면, 표 1에 리스트된 결함 표시값의 현재 상태에 대응하는 값이 전송된다. G1의 비트 8 (LSB)은 사용되지 않고, 0으로 설정된다.

-- 다른 POH 바이트

나머지 POH 바이트는 IOSL 디바이스에 의해 지지되지 않고, 모든 0인 고정 바이트로 전송된다. 이들은 경로 사용자 채널(F2), 위치 표시자(H4), 경로 성장/사용자 채널(Z3/F3), 경로 성장/경로 APS 채널(Z4/K3), 및 직렬 연결 모니터(Z5/N1) 바이트를 포함한다.

SONET/SDH 프레임 발생

SONET/SDH 프레임 발생 블록은 운송 (섹션) 오버헤드(Transprot (Section) Overhead, TOH/SOH) 바이트를 발생하고, SPE/VC로부터의 바이트로 페이로드를 채우고, 또한 TOH/SOH 바이트의 제1 로우 (row)를 제외한 모든 바이트의 SONET/SDH 신호를 스크램블 처리함으로서 STS-3c/STM-1을 생성한다.

- 프레임 정렬

발생된 프레임의 위치는 입력, TX_FRAME_IN에 대해 고정된다. 프레임 시작 표시 출력, TX_FRAME_OUT은 TX_FRAME_IN 입력에 대해 고정되지만 지정되지 않은 관계를 갖는다. 전송 라인 출력 TX_DATA[7:0]상의 데이터 바이트에 대한 TX_FRAME_OUT상의 1 클럭 싸이클폭 펄스의 관계는 IOS_TX_FOUT_BYTE_TYPE[1:0] 및 TX_FOUT_BYTE_NUMBER[3:0] 레지스터에 의해 제어된다.

- 페이로드 발생

SONET 또는 SDH 페이로드는 일반적으로 SPE/VC로부터의 바이트로 채워진다. SPE/VC의 J1 바이트는 STS-3c/STM-1 모드에서 로우 1의 컬럼 10으로 배치된다 (IOS_TX_SIG_MODE = 0).

-- AIS 발생

SONET/SDH 페이로드의 일반적인 발생은 라인 (멀티플렉스 섹션 (Multiplex Section), MS) 알람 표시 신호인 LAIS 또는 경로 (관리 유닛 (Administrative Unit), AU) AIS 신호인 PAIS를 전송하는 동안 중단된다. AIS 발생은 IOS_TX_LAIS 및 IOS_TX_PAIS 레지스터에 의해 제어된다. IOS_TX_LAIS 또는 IOS_TX_PAIS = 1이면, 전체 페이로드(9396 또는 2349 바이트)는 전부 1인 바이트로 채워진다.

-- 갖추어지지 않은 발생

AIS가 활성화되지 않으면, TX_UNEQ = 1인 경우, 갖추어지지 않은 SPE/VC가 (모든 SPE/VC 바이트가 모드 0으로 채워진다) 발생된다.

- TOH/SOH 발생

SONET TOH 바이트는 일반적으로 SDH SOH 바이트와 똑같다. 다음 섹션은 모든 TOH/SOH 바이트에 대해 발생되는 값을 정의한다. 바이트 명칭이 SONET과 SDH 사이에 서로 다른 경우, SONET 명칭이 먼저 리스트된다. 표준에서 비어있는 엔터티는 SONET 정의되지 않거나 SDH 비표준화된 예정 바이트이다. IOSL 디바이스는 이들 바이트를 모두 0으로 채운다.

-- AIS 발생

TOH/SOH 바이트의 정상적인 발생은 LAIS 또는 PAIS를 전송하는 동안 중단된다. IOS_TX_LAIS = 1이면, TOH/SOH의 처음 3개 로우는 정상적으로 발생되지만, 나머지 TOH/SOH (뿐만 아니라 모든 SPE/VC 바이트)는 모두 1인 바이트로 전송된다. IOS_TX_PAIS = 1이면, TOH/SOH의 모든 로우는 로우 4에서 포인터 바이트를 제외하고 정상적으로 발생된다. H1, H2, 및 H3 바이트 (뿐만 아니라 모든 SPE/VC 바이트)는 모두 1인 바이트로 전송된다.

-- 프레임 바이트 (A1 및 A2)

프레임 바이트는 고정 패턴을 가지고 정상적으로 발생된다:

* A1: 1111_0110 = F6

* A2: 0010_1000 = 28

테스트를 위해, Al 및 A2는 에러와 함께 발생될 수 있다. A1A2_ERR = 0이면, 에러가 삽입되지 않는다. A1A2_ERR가 1일 때, 8 프레임의 각 그룹에서 m개의 연속적인 프레임 (여기서, m은 A1A2_ERR_NUM[2:0]과 동일한 이진수)은A1A2_ERR_PAT[15:0]의 내용과 XOR 처리된 A1 및 A2로 발생된다. A1의 MSB는 A1A2_ERR_PAT[15]와 XOR 처리되고, A2의 LSB는 A1A2_ERR_PAT[0]과 XOR 처리된다.

-- 섹션 트레이스/재발생 섹션 트레이스(J0) 및 섹션 성장/여분(Z0) 섹션 트레이스

16개의 연속 프레임 주기에 걸쳐, IOSL 디바이스는 IOS_TX_J0_[15:0]_[7:0]에 포함된 16-바이트 패턴을 연속적으로 전송한다. 바이트는 IOS_TX_J0_[15]_[7:0]으로 시작하여 내림차순으로 전송된다.

ITU-T G.707 표준은 clause3/G.831에서 정의된 SAPI (Section Access Point Identifier)를 포함하는 16-바이트 섹션 트레이스 프레임이 연속적인 J0 바이트에서 계속 전송되어야 한다고 기술한다. 프레임 시작 표시자 바이트만이 MSB에 1을 포함함을 주목한다.

섹션 트레이스 기능은 기존에 SONET에 대해 정의되지 않는다. SONET에 대해 유사한 섹션 트레이스가 정의되지 않으면, 모든 IOS_TX_J0 바이트는 10진수 1이 J0에서 연속하여 전송되도록 0000_0001로 채워져야 한다.

섹션 성장/여분. Z0 바이트는 STS-12c/STM-4 (IOS_TX_SIG_MODE = 1) 모드에서 2 내지 12, STS-3c/STM-1 (IOS_TX_SIG_MODE = 0) 모드에서 2 내지 3과 똑같은 이진수로 순서대로 전송된다 (이는 GR-253에서 지정된다).

-- 섹션 BIP-8 (B1)

B1 비트 인터리브 패리티 8 (BIP-8)은 IOS_BI_INV = 0인 경우 짝수 패리티 (정상)로 전송된다. 그렇지 않으면, 홀수 패리티 (부정확)가 발생된다. BIP-8은스크램블 처리 이후에 이전 STS-3c/STM-1 프레임의 모든 비트에 걸쳐 계산되고, 스크램블 처리 이전에 현재 프레임의 B1 바이트에 배치된다. BIP-8의 정의에 의해, B1의 제1 비트는 이전 프레임의 모든 바이트 중 제1 비트를 통해 패리티를 제공하고, B1의 제2 비트는 이전 프레임의 모든 바이트 중 제2 비트를 통해 패리티를 제공한다.

-- 오더와이어 (Orderwire) (E1 및 E2)와 섹션 사용자 채널 (F1)

오더와이어 바이트는 2개의 64kb/s 디지털화 음성 신호를 운반하기 위해 정의된다. F1 바이트는 네트워크 제공자에 의한 사용에 이용가능하다. 전송 블록은 전송된 E1, E2, 및 F1 바이트로의 삽입을 위해 3개의 직렬 입력, IOS_TX_E1_DATA, IOS_TX_E2_DATA, 및 TX_F1_DATA를 수용한다. 이들 3개의 직렬 입력에 대한 타이밍 기준을 제공하기 위해 IOSL 디바이스로부터 단일 64kHz 클럭 (IOS_TX_E1E2F1_CLK)이 출력된다.

이들 바이트의 제1 비트 (MSB)는 들어오는 프레임 시작 펄스, IOS_TX_FRAME_IN와 정렬되어야 한다. 수신된 E1, E2, 및 F1 바이트는 E1, E2, 및 F1 바이트의 최종 비트 수신에 이어지는 출력 SONET/SDH 프레임에 삽입된다.

-- 데이터 통신 채널 DCC (D1-D12)

TOH/SOH에는 2개의 DCC (data communication channel)가 있다. 섹션/재발생 섹션 DCC는 192kb/s 채널을 생성하는데 D1, D2, 및 D3 바이트를 사용한다. 라인/멀티플렉스 섹션 DCC은 576kb/s 채널을 생성하는데 D4 내지 D12를 사용한다. 전송측은 2개의 직렬 입력, IOS_TX_SDCC_DATA 및 IOS_TX_LDCC_DATA에서 DCC 데이터를받아들인다. 비트 동기화를 보장하기 위해, 전송측은 2개의 클럭, 즉 192kHz에서 IOS_TX_SDCC_CLK 및 576kHz에서 IOS_TX_LDCC_CLK를 출력한다. 클럭 신호는 TOH/SOH로 삽입하도록 IOS_TX_SDCC_DATA 및 IOS_TX_LDCC_DATA로부터 레지스터로 비트의 재타이밍을 인에이블시킨다. 재타이밍이 상승 엣지에서 실행되므로, IOS_TX_SDCC_DATA 및 IOS_TX_LDCC_DATA는 IOS_TX_SDCC_CLK 및 IOS_TX_LDCC_CLK의 하강 엣지에서 변화되어야 한다.

-- 포인터 바이트 (H1, H2) 및 포인터 작용 바이트 (H3)

H1 및 H2는 3개의 필드를 포함한다. SPE/VC가 TOH와 동기화되어 발생되기 때문에, 가변 포인터 발생이 요구되지 않는다. 대신에, 활성화 H1 및 H2 바이트가 522 (10진수) = 10_0000_1010 (2진수)의 고정된 포인터값으로 발생되고, H3 바이트는 모두 0으로 고정된다. 그래서, J1 바이트의 SPE/VC는 STS-3c/STM-1 모드(IOS_TX_SIG_MODE = 0)에서 로우 1의 컬럼 10으로 배치된다.

AIS 발생. IOS_TX_LAIS 또는 TX_PAIS가 활성화 상태이면, H1, H2, 및 H3 바이트는 모두 1로 전송된다. 모든 비트가 0이 되도록 IOS_TX_LASI 또는 TX_PAIS가 전이될 때, IOSL 디바이스는 인에이블된 새로운 데이터 플래그로 다음 프레임에서 제1 H1 바이트를 전송한다. 이어지는 프레임은 제1 H1 바이트에서 디스에이블된 NDF 필드로 발생된다.

비-AIS 발생. 처음 H1-H2 바이트쌍은 명목상 포인터로 다음과 같이 전송된다.

* NDF = 0110

* SS = TX_SDH_PG, 0

* 포인터값 = 10_0000_1010

다른 모든 H1-H2 바이트쌍은 다음과 같이 연속 표시 바이트로 전송된다.

* NDF = 1001

* SS = TX_SDH_PG, 0

* 포인터값 = 11_1111_1111

-- 라인/MS BIP-96/24 (B2)

다음의 B2 설명에서, 숫자들은 디바이스의 모드에 의존하여 약간 변한다 (STS-12c 모드 대 STS-3c). 두 경우의 동작을 설명하기 위해, 다음은 각 모드에 적용되는 요구조건을 식별하는데 사용된다: STS-3c. TOH/SOH에는 12 [3] B2 바이트가 있고, 그와 함께 이는 BIP-96 [BIP-24] 에러 검출 기능을 제공한다.

각 B2 바이트는 이전 프레임에서 12 [3] 바이트 그룹 중 1의 바이트를 통해 BIP-8 패리티를 제공한다. 컬럼 j의 B2 바이트는 컬럼 j + 12k (j + 3k) (여기서, k = 0 내지 89)에서 나타나는 이전 프레임 (TOH/SOH의 처음 3 로우의 바이트를 제외하고)의 바이트를 통해 BIP-8 패리티를 제공한다. BIP-8은 B2_INV = 0인 경우 짝수 패리티 (정상)로 전송된다. 그렇지 않으면, 홀수 패리티 (부정확)가 발생된다. BIP-8 값은 스크램블 처리 이전에 이전 STS-3c/STM-1 프레임의 바이트를 통해 계산되고, 스크램블 처리 이후에 현재 프레임의 B2 바이트로 배치된다.

-- APS 채널 및 라인/MS AIS/RDI (K1 및 K2)

K1 및 K2의 5 MSB는 APS (automatic protection switching) 신호 전송에 사용된다. K2의 3 LSB는 라인/MS 레벨에서 AIS 또는 RDI (Remote Defect Indication)로 사용되고, SONET에서는 이들이 또한 APS 신호 전송에 사용된다. IOSL 디바이스는 전송된 K1 바이트에 IOS_TX_K1_[7:0]을 삽입하고, 전송된 K2 바이트의 5 MSB에 IOS_TX_K2_[7:3]을 삽입한다.

K2의 3 LSB는 3개 소스로부터 제어된다. 우선순위로, 이는 다음과 같다.

* TX_LAIS = 1이면, 모두 1로 전송된다 (모든 라인/MS 오버헤드 바이트와 같이).

* 그밖에, LRDI_INH = 0이고 (IOS_RX_LOS AND NOT RX_LOS_INH), IOS_RX_LOF, IOS_RX_LOC 중 임의의 것, 또는 IOS_RX_LAIS = 1이면, 이들은 110으로 전송된다. 이 특정 이벤트가 활성화 상태일 때, K2는 최소 20 프레임 동안 110으로 설정된다.

* 그밖에는 IOS_TX_K2_[2:0]이 전송된다.

RX_LOS는 활성화 고상태 (IOS_RX_LOS_LEVEL = 0, 디폴트) 또는 활성화 저상태 (IOS_RX_LOS_LEVEL = 1)가 될 수 있다. 내부적으로, IOS_RX_LOS_LEVEL = 1이면, IOS_RX_LOS는 반전되어 IOS_RX_LOS를 제공한다. GR-253의 요구조건 R6-180 내지 R6-182는 수신된 LOS, LOF, 또는 LAIS의 검출 및 제거에서 RDI가 삽입되어 125 μs내에서 제거되어야 한다고 지정한다.

-- 동기화 상태 (S1)

이 바이트의 4 LSB는 동기화 상태 메시지를 운반한다. 전송된 S1 바이트는 IOS_TX_S1_[7:0]과 동일하게 설정된다.

-- 라인/MS REI (M1)

수신측은 수신된 신호에서 B2 비트 에러를 모니터한다. 각 프레임에서 에러 검출된 B2의 수는 STS-12c/STM-4 모드에서 프레임 당 0 내지 96 B2 비트, 또한 STS-3c/STM-1 모드에서 프레임 당 0 내지 24 B2 비트의 범위가 될 수 있다. 라인/MS REI (Remote Error Indication) 바이트, M1 바이트는 일반적으로 수신된 신호에서 검출된 B2 에러의 카운트를 운반한다.

사용자는 TX_M1_ERR = 1을 설정함으로서 REI 에러 표시의 전송을 강요할 수 있다. 이는 24 (STS-3c/STM-1 모드)의 카운트가 M1 바이트에서 전송되게 한다. 그밖에, LREI_INH = 0이면, M1 바이트는 가장 최근의 B2 에러 카운트와 똑같이 설정된다. 그렇지 않으면, M1 바이트는 모드 0으로 설정된다.

-- 성장/비정의 (Z1 및 Z2)

Z1 및 Z2 바이트의 사용은 표준화되지 않는다. IOSL 디바이스는 이들 바이트를 모두 0으로 채운다.

HDLC 프레임화에서의 스크램블 처리

입력은 다항식 g(x) = x⁷+ x⁶+ 1로부터 발생된 프레임 동기화 스크램블 시퀀스로 스크램블 처리된다. 스크램블러는 처음 SPE/VC 바이트 (STS-3c/STM-1 모드에서 로우 1의 컬럼 10에 있는 바이트)가 시작될 때 1111111로 초기화되고, TOH/SOH의 제1 로우를 제외하고 전체 SONET/SDH 신호를 스크램블 처리한다. 테스트를 위해, 스크램블러는 SCRINH 비트를 1로 설정함으로서 디스에이블될 수 있다.

상술된 바와 같이, LAPS 프레임은 SDH/SONET 프레임의 SPE/VC에서 캡슐화된다. LAPS 프레임은 연속으로 하나 이상의 가상 컨테이너 (Virtual Container)에 걸쳐 포함될 수 있다. 삽입된 포인터는 페이로드인 가상 컨테이너의 시작을 나타낸다.

이후에는 본 발명의 한 실시예에 따라 수신 방향의 데이터 처리를 설명한다.

수신 방향의 데이터 처리

T-대-R 루프백 및 LOC

IOSL 수신 섹션은 R_LOOP = 1인 경우에 발생된 전송 신호를 루프백하도록 구성될 수 있다. 그렇지 않으면, SONET/SDH 인터페이스로부터의 수신 신호가 선택된다. 루프백하는 동안, TX_SONETCLK 입력은 수신기 프레이머 및 다른 수신기 회로에 클럭을 제공하는데 사용된다. 루프백이 선택되지 않으면, RX_SONETCLK 입력이 이 회로에 클럭을 제공하는데 사용된다.

RX_SONETCLK 입력은 TX_CLK 입력을 사용하여 클럭의 손실에 대해 모니터된다. 16 주기의 TX_CLK 동안 RX_SONETCLK에 전이가 검출되지 않으면, RX_LOC 비트가 설정된다. 이는 전이가 검출될 때 클리어된다. RX_LOC_D 델타 비트는 RX_LOC가 0에서 1 또는 1에서 0으로 전이되면 설정된다.

운송 오버헤드 모니터

TOH/SOH 모니터 블록은 J0, B2, K1K2, S1, 및 M1 모니터로 구성된다. 이들 TOH/SOH 바이트는 상태의 변화나 에러에 대해 모니터된다.

- J0 모니터

J0 모니터에는 2가지 모드의 동작이 있다. 한가지는 전형적으로 SONET 응용에 사용되고, 다른 하나는 SDH 응용에 사용된다. IOS_RX_J0 = 0 모드(SONET)에서, J0 모니터는 3개의 연속적인 프레임 동안 일관되게 정합되는 값에 대해 수신된 J0 바이트를 조사하는 것으로 구성된다. 일관된 J0 값이 수신될 때, 이는 IOS_RX_J0_[15]_[7:0]에 기록된다.

IOS_RX_J0 = 1인 경우 (SDH), J0 바이트는 섹션 억세스점 식별자를 포함하는 반복적인 16-바이트 섹션 트레이스 프레임을 포함할 것으로 기대된다. J0 모니터는 16-바이트 섹션 트레이스 프레임의 시작에 고정되고, 3개의 연속적인 섹션 트레이스 프레임 동안 일관되게 정합되는 값에 대해 수신된 섹션 트레이스 프레임을 조사하는 것으로 구성된다. 일관된 프레임 값이 수신될 때, 이는 IOS_RX_J0_[15:0]_[7:0]에 기록된다. 제1 바이트 섹션 트레이스 프레임 (프레임 시작 표시자를 포함하는)은 IOS_RX_J0_[15])[7:0]에 기록된다.

-- 프레임화

프레임 시작 표시자 바이트의 MSB를 제외하고, 모든 섹션 트레이스 프레임 바이트의 MSB는 0이다. J0 모니터 프레이머는 MSB에 0을 갖고, MSB에 1를 갖는 J0 바이트로 이어지는 15개의 연속적인 J0 바이트를 탐색한다. 이 패턴이 발견될 때, 프레이머는 프레임, J0_OOF = 0으로 진행된다. 일단 J0 모니터 프레이머가 프레임내에 있으면, 이는 3개의 연속적인 섹션 트레이스 프레임이 적어도 1 MSB 비트 에러를 갖고 수신될 때까지 프레임내에 유지된다. IOS_RX_J0 = 0이면, J0 프레임 표시는 프레임내 상태, ISO_J0_OOF = 0으로 유지된다. IOS_J0_OOF_D 델타 데이터는 IOS_J0_OOF가 상태를 변화시킬 때 설정된다.

-- 패턴 수용 및 비교

프레임에서 한번씩, J0 모니터 블록은 3개의 연속적인 16바이트 (IOS_RX_J0 = 1) 또는 1 바이트 (IOS_RX_J0 = 0) 섹션 트레이스 프레임을 찾는다. 3개의 연속적인 동일 프레임이 수신될 때, 받아들여진 프레임은 IOS_RX_J0_[15:0]_[7:0] (또는 SONET 모드에서 IOS_RX_J0_[15]_[7:0])에 저장된다. 수용 프레임은 이들 레지스터의 이전 내용에 비교된다. 새로운 값이 저장될 때, IOS_RX_J0_D 델타 비트가 설정된다.

- BIP-96 (B2) 점검

다음의 B2 설명에서, 숫자들은 디바이스의 모드(STS-3c)에 의존하여 약간 변화된다. 두가지 경우의 동작을 설명하기 위해, 다음은 모드: STS-3c에 적용하는 요구조건을 식별하는데 사용된다. IOSL 디바이스는 정확한 BIP-8 값에 대해 수신된 B2 바이트를 점검한다. (12 [3] B2 바이트는 함께 BIP-96 [BIP-24]을 형성한다.) 짝수 패리티 BIP-96 [BIP-24]는 TOH (SONET에서는 SOH이고 SDH에서는 RSOH)의 처음 3 로우를 제외하고 각 프레임의 12 [3] 바이트의 모든 그룹에 걸쳐 계산된다. 계산은 디스크램블 처리 이후에 수신된 데이터에 실행된다. 이 값은 이어서 디스크램블 처리 이후 다음 프레임에서 B2 값에 비교된다. 비교 결과는 0 내지 96 [0 내지 24] 부정합 (B2 비트 에러)으로 주어질 수 있다. 각 프레임에서 에러 검출된 B2 비트의 수는 전송된 M1 바이트로 삽입될 수 있다.

-- B2 에러 카운트

IOSL 디바이스는 모든 B2 비트 에러 (BIT_BLKCNT = 0인 경우) 또는 적어도하나의 B2 비트 에러를 갖는 모든 프레임 (BIT_BLKCNT = 1인 경우)을 카운트하는 20-비트 B2 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이), 이 카운터의 값은 B2_ERRCNT[19:0] 레지스터로 래치되고, B2 에러 카운터는 클리어된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 B2 에러가 있으면, B2 에러 제2 이벤트 비트, B2ERR_SECE가 설정된다. B2 에러 비율 한계값 블록이 적용된다.

수신된 신호의 비트 에러 비율이 제공가능한 2가지의 다른 한계값 (신호 실패 (Signal Fail) 및 신호 변형 (Signal Degrade) 조건) 이상 또는 이하인가 여부를 결정하기 위해, IOSL 디바이스는 2개의 B2 에러 비율 한계값 블록을 제공한다. 에러 비율이 한계값 이상인 것으로 SF 블록 또는 SD 블록이 결정하면, B2_ERR_SF 또는 B2_ERR_SD를 설정한다. 델타 비트 B2_ERR_SF_D 또는 B2_ERR_SD_D는 대응하는 에러 비율 비트가 값을 변화시키는 경우 설정된다. 각 에러 비율 한계값 블록에 대해, 사용자는 BLOCK 레지스터 및 2쌍의 THRESH 및 GROUP 레지스터를 제공할 수 있다. 상태 설정하고 클리어할 때 히스테리시스(hysteresis)를 허용하기 위해, 각 에러 비율 한계값 블록은 상태를 설정하기 위한 1쌍의 THRESH 및 GROUP 레지스터 및 상태를 클리어하기 위한 1쌍의 THRESH 및 GROUP 레지스터를 갖는다. 그래서, 에러 비율 한계값 블록에서 사용되는 레지스터는 다음과 같다.

* B2_ERR_SF = 0인 동안, B2_BLOCK_SF[7:0], B2_THRESH_SET_SF[7:0], 및 B2_GROUP_SET_SF[5:0]을 사용하여 설정되어야 하는가를 결정한다.

* B2_ERR_SF = 1인 동안, B2_BLOCK_SF[7:0], B2_THRESH_CLR_SF[7:0], 및B2_GROUP_CLR_SF[5:0]을 사용하여 클리어되어야 하는가를 결정한다.

* B2_ERR_SD = 0인 동안, B2_BLOCK_SD[15:0], B2_THRESH_SET_SD[5:0], 및 B2_GROUP_SET_SD[5:0]을 사용하여 설정되어야 하는가를 결정한다.

* B2_ERR_SD = 1인 동안, B2_BLOCK_SD[15:0], B2_THRESH_CLR_SD[5:0], 및 B2_GROUP_CLR_SD[5:0]을 사용하여 설정되어야 하는가를 결정한다.

K1K2 모니터링

라인/MS AIS 또는 RDI를 전달하고 APS 신호 전송에 사용되는 K1 및 K2 바이트는 상태 변화에 대해 모니터된다.

- 라인/MS AIS 모니터 및 LRDI 발생

K2의 3 LSB는 라인/MS 레벨에서 AIS 또는 RDI (Remote Defect Indication)로 사용될 수 있다.

이것이 K2_CONSEC[3:0] 연속 프레임 동안 "111"로 수신되면, RX_LAIS가 설정되고, RX_LAIS_OUT 출력은 고상태이다. K2_CONSEC[3:0] 연속 프레임 동안 "111"로 수신되지 않으면, RX_LAIS 및 RX_LAIS_OUT은 클리어된다. RX_LAIS_D 델타 비트는 RX_LAIS가 상태를 변화시킬 때 설정된다.

- 라인/MS RDI 모니터

K2의 3 LSB는 또한 K2_CONSEC[3:0] 연속 수신 또는 "110"의 비수신 동안 모니터된다. 이것이 수신될 때, RX_LRDI는 설정 또는 클리어된다. RX_LRDI_D는 RX_LRDI가 상태를 변화시킬 때 설정된다.

- APS 모니터

APS 요구 및 채널수를 전달하는데 사용되는 K1 바이트 및 K2 바이트의 4 MSB가 3개의 연속 프레임 동안 동일하게 수신되면, 그 값들은 RX_K1_[7:0] 및 RX_K2_[7:4]에 기록된다. 수용된 값은 이들 레지스터의 이전 내용과 비교되고, 새로운 12-비트 값이 저장될 때, RX_K1_D 델타 비트가 설정된다.

K1 바이트는 불안전성에 대해 점검된다. 12개의 연속 프레임 동안 3개의 연속 프레임이 동일한 K1 바이트로 수신되지 않으면, K1_UNSTAB 비트가 설정된다. 이는 3개의 연속 동일 K1 바이트가 수신될 때 클리어된다. K1_UNSTAB가 상태를 변화시킬 때, K1_UNSTAB_D 델타 비트가 설정된다. K2의 비트 3 내지 0은 APS 모드 정보를 포함한다. 이들 비트는 K2_CONSEC[3:0] 연속 동일값에 대해 모니터된다. K2의 비트 2 및 1의 값이 "11"이 아니면 (라인/MS AIS 또는 RDI를 나타내는), 발생될 때 RX_K2_[3:0]이 기록된다. RX_K2_D 델타 비트는 새로운 값이 RX_K2_[3:0]에 기록될 때 설정된다.

APS 모니터와 연관된 3개의 델타 비트, IOS_RX_K1_D, RX_K2_D, 및 IOS_K1_UNSTAB_D는 모두 APS 인터럽트 신호, APS_INTB에 기여한다. 부가하여, 이들 3개의 델타 비트는 또한 표준 요약 인터럽트 신호, INTB에 기여한다.

- S1 모니터

수신된 S1 바이트의 4 LSB는 SONET 모드(IOS_RX_SDH_S1 = 0)에서 8개의 연속 프레임 또는 SDH 모드(IOS_RX_SDH_S1 = 1)에서 3개의 연속 프레임의 일관된 값에 대해 모니터된다. 이들 비트가 일관된 동기화 상태 메시지를 포함할 때, 수용된 값은 RX_S1_[3:0]에 기록된다. 수용된 값은 이 레지스터의 이전 내용에 비교되고,새로운 값이 저장될 때, IOS_RX_S1_D 델타 비트가 설정된다. S1 바이트는 또한 메시지 실패에 대해 점검된다. 메시지가 LATCH_EVENT의 최종 상승 엣지 이래로 임의의 시간에 상기 확인 기준 (이것이 마지막으로 수용된 값과 다르거나 똑같은가 여부)을 만족시키지 않으면, S1 실패 제2 이벤트 비트, S1_FAIL_SECE가 설정된다.

- M1 모니터

M1 바이트는 수신된 신호에서 원격 단자에 의해 검출되었던 B2 에러의 수를 나타낸다. IOSL 디바이스는 M1으로 나타내지는 모든 에러 (BIT_BLKCNT = 0인 경우) 또는 0이 아닌 M1을 갖는 모든 프레임 (BIT_BLKCNT = 1인 경우)을 카운트하는 20-비트 M1 에러 카운터를 포함한다. IOS_RX_SIG_MODE = 1일 때, BIT_BLKCNT = 0에서 M1의 유효한 값은 0 내지 96이고; 다른 값은 0 에러인 것으로 해석된다. RX_SIG_MODE = 0이고 BIT_BLKCNT = 0일 때, M1의 유효한 값은 0 내지 24이고; 다른 값은 0 에러인 것으로 해석된다. 성능 모니터 카운터가 래치될 때, 이 카운터의 값은 M1_ERRCNT[19:0] 레지스터로 래치되고, M1 에러 카운터는 클리어된다.

LATCH_EVENT의 최종 하강 엣지 이래로 적어도 하나의 수신된 M1 에러 표시가 있으면, M1 에러 제2 이벤트 비트, M1_ERR_SECE가 설정된다.

운송 오버헤드 드롭

TOH/SOH 드롭 (drop) 블록은 수신된 E1, F1, 및 E2 바이트와 2개의 직렬 DCC 채널을 출력한다.

- 오더와이어 (E1 및 E2)와 섹션 사용자 채널 (F1)

3개의 직렬 출력, IOS_RX_E1_DATA, IOS_RX_E2_DATA, 및 IOS_RX_F1_DATA는 수신된 E1, E2, 및 F1 바이트의 값을 포함한다. 신호 64kHz 클럭 기준 출력 (IOS_RX_E1E2F1_CLK)이 또한 제공된다. E1, E2, 및 F1 바이트의 MSB는 RX_FRAME_OUT의 상승 엣지 이후에 처음 64kHz 클럭 싸이클에서 나타난다.

- 데이터 통신 채널, DCC (D1-D12)

TOH/SOH에는 2개의 DCC가 정의된다. 섹션/재발생 섹션 DCC는 192kb/s 채널을 생성하는데 D1, D2, 및 D3 바이트를 사용한다. 라인/멀티플렉스 섹션 DCC는 576kb/s 채널을 생성하는데 바이트 D4 내지 D12를 사용한다. TOH/SOH 드롭 블록은 2개의 직렬 채널, RX_SDCC_DATA 및 RX_LDCC_DATA로 DCC 데이터를 출력한다. 이들 채널은 출력 IOS_RX_SDCC_CLK 및 IOS_RX_LDCC_CLK에 동기화된다. DCC 데이터 출력은 RX_SDCC_CLK 및 RX_LDCC_CLK의 하강 엣지에서 변화된다.

포인터 상태 결정 또는 포인터 해석

포인터 상태 결정은 STS-3c/AU-4 수신 포인터의 상태를 정하도록 H1-H2 바이트를 조사하는 것을 포함한다.

- 상태 전이 규칙

다음 포인터 상태 결정 설명에서는 디바이스의 모드(STS-3c)에 의존하여 숫자들이 약간 변화된다. 두 경우의 동작을 모두 설명하기 위해 다음은 모드에 적용되는 요구조건을 식별하는데 사용된다: STS-3c.

제1 쌍의 H1-H2 바이트는 STS-3c/AU-4 포인터를 포함한다. 이들은 모니터되고 다음 3 상태 중 하나인 것으로 생각된다:

* 정상 (NORM = 00)

* 알람 표시 신호 (AIS = 01)

* 포인터의 손실 (LOP = 10)

나머지 11 [2] 쌍의 H1-H2 바이트는 정확한 연결 표시를 위해 모니터된다. 이들은 다음 3 상태 중 하나인 것으로 생각된다:

* 연결 (CONC = 11)

* 알람 표시 신호 (AISC = 01)

* 포인터의 손실 (LOPC = 10)

각 상태는 IOS_PTR_STATE_[1:12]_[1:0] [IOS_PTR_STATE_[1:3]_[1:0]]에 저장되고, 여기서 IOS_PTR_STATE_[i]_[1:0]은 H1-H2 바이트의 제i 쌍의 상태를 나타낸다. H1-H2 바이트의 각 쌍의 상태는 이어서 STS-3c/AU-4 포인터의 상태를 결정하도록 조합된다.

- STS-3c/AU-4 포인터의 상태

IOSL 디바이스는 수신된 STS-3c/AU-4 포인터의 포인터 상태를 나타내는 레지스터 상태 비트 IOS_RX_PAIS 및 IOS_RX_LOP를 공급한다. 이들은 3 상태 중 하나가 될 수 있다:

* 정상 (IOS_RX_PAIS = 0 및 RX_LOP = 0) - IOS_PTR_STATE_[1]_[1:0]은 NORM(00)이고 다른 모든 PRT_STATE_[i]_[1:0]은 CONC(11)이다.

* 경로/AU AIS (IOS_RX_PAIS = 1 및 RX_LOP = 0) - 모든 PTR_STATE_[i]_[1:0]은 AIS 또는 AISC(01)이다.

* 포인터의 손실 (IOS_RX_PAIS = 0 및 IOS_RX_LOP = 1) - 다른 모든 것(PTR_STATE_[i]_[1:0] 값이 정상이나 경로/AU AIS 기준을 만족시키지 못한다).

IOS_RX_PAIS 및 IOS_RX_LOP 신호는 PRDI (Path Remote Defect Indication)에 기여한다. 이들 상태값의 변화는 IOS_RX_PAIS_D 및 IOS_RX_LOP_D 델타 비트로 나타내진다.

포인터 해석 유닛

도 7의 포인터 해석 유닛(28)에서, 제1 H1-H2 바이트쌍은 SPE/VC의 시작 위치를 정하도록 해석된다. 포인터 해석 규칙은 다음과 같다:

1. 정상 동작 동안, 포인터는 SPE/VC의 시작 위치를 정한다.

2. 일관된 새로운 값이 연속적으로 3회 수신되지 않거나, 규칙 3, 4, 또는 5 중 하나로 선행되지 않으면, 현재 수용된 포인터로부터의 변화는 무시된다. 연속적으로 3회 수신되는 일관된 새로운 값은 규칙 3 또는 4를 무시한다.

3. IOS_RX_SDH_PI = 0의 경우, NDF 비트의 4 중 적어도 3개가 디스에이블된 표시 (0110)와 정합되고, 포인터값 비트의 10 중 적어도 8개가 반전된 I-비트를 갖는 현재 수용된 포인터와 정합되면, 긍정 판정이 나타내진다. H3 바이트에 이어지는 바이트는 양의 스터프 (stuff) 바이트로 생각되고, 현재 수용된 포인터값은 1 만큼 증가된다 (mod 783).

IOS_RX_SDH_PI = 1의 경우, NDF 비트의 4 중 적어도 3개가 디스에이블된 표시 (0110)와 정합되고, 포인터값 I-비트 중 3개 이상 또는 포인터값 D-비트 중 2개 이하가 모두 반전된 비트를 갖는 현재 수용된 포인터와 정합되고, 수신된 SS-비트가 10이거나 IOS_RX_SS_EN = 0이면, 긍정 판정이 나타내진다. H3 바이트에 이어지는 바이트는 양의 스터프 바이트로 생각되고, 현재 수용된 포인터값은 1 만큼 증가된다 (mod 783).

4. IOS_RX_SDH_PI = 0의 경우, NDF 비트의 4 중 적어도 3개가 디스에이블된 표시 (0110)와 정합되고, 포인터값 비트의 10 중 적어도 8개가 반전된 D-비트를 갖는 현재 수용된 포인터와 정합되면, 부정 판정이 나타내진다. H3 바이트는 음의 스터프 바이트 (이는 SPE의 일부)로 생각되고, 현재 수용된 포인터값은 1 만큼 증가된다 (mod 783).

IOS_RX_SDH_PI = 1의 경우, NDF 비트의 4 중 적어도 3개가 디스에이블된 표시 (0110)와 정합되고, 포인터값 D-비트 중 3개 이상 또는 포인터값 I-비트 중 2개 이하가 모두 반전된 비트를 갖는 현재 수용된 포인터와 정합되고, 수신된 SS-비트가 10이거나 IOS_RX_SS_EN = 0이면, 부정 판정이 나타내진다. H3 바이트는 음의 스터프 바이트 (이는 VC의 일부)로 생각되고, 현재 수용된 포인터값은 1 만큼 증가된다 (mod 783).

5. IOS_RX_SDH_PI = 0의 경우, NDF 비트의 4 중 적어도 3개가 인에이블된 표시 (1001)와 정합되고, 포인터값이 0과 782 사이이면, 수신된 포인터는 현재 수용된 포인터값과 대치된다.

IOS_RX_SDH_PI = 1에서, NDF 비트의 4 중 적어도 3개가 인에이블된 표시 (1001)와 정합되고, 포인터값이 0과 782 사이이고, 또한 수신된 SS-비트가 10이거나 IOS_RX_SS_EN = 0이면, 수신된 포인터는 현재 수용된 포인터값과 대치된다.

이러한 포인터 해석 규칙을 사용하여, 포인터 해석기 블록은 SPE/VC 페이로드 및 POH 바이트의 위치를 결정한다.

- 포인터 처리

IOSL 디바이스에서 실시되는 포인터 트래킹 (tracking) 알고리즘에 대한 것이다. 포인터 트래킹 상태 기계는 ITU-T 요구조건에서 발견된 포인터 트래킹 상태 기계를 근거로 하고, 또한 Bellcore 및 ANSI 모두에 유효하다. 상태 기계의 AIS 대 LOP 전이는 Bellcore 모드에서 (즉, BELLCORE 비트를 논리 1로 설정함으로서) 일어나지 않는다.

각 AU-4/STS-3c에 대해 하나씩 4개의 포인터 트래킹 상태 기계가 사용된다. 포인터 트래킹은 H11 및 H21 바이트를 사용한다. 포인터는 H1n 및 H2n 바이트의 연속으로부터 추출되고, 다음과 같이 해석된다:

N = 새로운 데이터 플래그 비트. 이는 인에이블 = 1001 또는 0001/1101/1011/1000, 및 정상 또는 디스에이블 = 0110 또는 1110/0010/0100/0111 (즉, 단일-비트 에러가 허용되는)으로 해석된다.

SS = 0으로 설정된 BELLCORE 제어 비트에 의해 인에이블되면 포인터 트래킹 상태 기계 해석에서 사용되는 크기 비트. BELLCORE가 1로 설정될 때, 이들 비트는 무시되지만, 0으로 설정될 때는 10인 것으로 기대된다.

I = H1n의 비트 7 및 H2n의 비트 1, 3, 5, 및 7로 정의된 증가 비트.

D = H1n의 비트 8 및 H2n의 비트 2, 4, 6, 및 8로 정의된 감소 비트.

부정 판정: 반전된 5 D-비트 및 다수결 원리 수용. [GR-253]에서 O3-92의 10개 목표 중 8개는 OR#Conf3 내지 0에서 ITU 비트만을 설정함으로서 인에이블될수 있다.

긍정 판정: 반전된 5 I-비트 및 다수결 원리 수용. [GR-253]에서 O3-92의 10개 목표 중 8개는 OR#Conf3 내지 0에서 ITU 비트만을 설정함으로서 인에이블될 수 있다.

STM-1/STS-3c 동작에서, 포인터는 0 내지 782 (10진수)의 범위를 갖는 2진수이다. 이는 H3 바이트 위치로부터 3-바이트 카운트의 오프셋 (offset)을 형성하도록, 연속된 H2 바이트와 함께, H1 바이트 중 2개의 최하위 비트로부터 유도된 10-비트 값이다. 예를 들면, STM-1 신호에서, 0의 포인터값은 VC-4가 H3 바이트 이후 바이트 위치 3 바이트에서 시작됨을 나타내고, 87의 오프셋은 VC-4가 K2 바이트 이후 3 바이트로 시작됨을 나타낸다.

STM-4/STS-12 모드에서는 4 바이트-인터리브 처리된 AU-4가 있으므로, 각 VC-4의 시작부 (즉, J1 바이트 위치)를 결정하기 위한 4개의 H1/H2 바이트쌍이 있다. 이 경우, 4개 포인터 트래킹 상태 기계의 동작은 4 x STM-1/STS-3c 동작과 유사하다.

STS-12c/STM-4c를 다룰 때, 매크로 (macro) 1에 대한 포인터 트래킹 상태 기계는 VC-4-4c의 시작 위치를 정하는데 사용된다. 포인터 트래킹은 H11 및 H21 바이트를 사용한다. 포인터는 H11 및 H21 바이트의 연속에서 추출되고, 상기에 도시된 바와 같이 해석된다. 그러나, 형성된 오프셋은 H3 바이트 위치로부터 12-바이트 카운트의 수를 나타낸다. 예를 들면, STM-12c 신호에서, 0의 포인터값은 VC-4가 H3 바이트 이후 바이트 위치 12 바이트에서 시작됨을 나타내고, 87의 오프셋은VC-4가 K2 바이트 이후 12 바이트로 시작됨을 나타낸다. 연속 표시 바이트는 또한 대응하는 매크로 (매크로 2-4)에서 조사되고, [G.783]의 부록 C에서 상기 기계 당 LOP 및 HPAIS에 대해 모니터된다. 이후의 상태도는 연속 표시자 상태 전이를 설명한다. 전이의 정의에 대해서는 [G.783]을 참고한다.

부가하여, 긍정 및 부정 판정 이벤트 뿐만 아니라 NDF 이벤트를 카운트하기 위해 8-비트 카운터가 제공된다. 상태 비트는 부정 판정, 긍정 판정, NDF, 무효 포인터, 새로운 포인터, 및 연속 표시의 검출을 나타내도록 제공된다. 상기 도면에 나타내진 바와 같이 LOP 또는 LOPC 상태에 들어갈 때, 대응하는 OR#IRQ2 레지스터에서 LOP 인터럽트 요구 비트가 설정된다. 유사하게, AIS 또는 AISC 상태에 들어갈 때, 대응하는 HPAIS 인터럽트 요구가 설정된다.

경로 오버헤드 모니터

POH 모니터 블록은 J1, B3, C2, 및 G1 모니터로 구성된다. 이들 POH 바이트는 상태의 변화 또는 에러에 대해 모니터된다.

- 경로 트레이스(J1) 포착/모니터

J1 삽입과 같이, IOSL 디바이스는 2가지 방법의 경로 트레이스(J1) 포착을 지지한다. SONET 응용에서 전형적으로 사용되는 첫번째 것은 STS-3c/AU-4에서 64개의 연속적인 J1 바이트를 포착한다. SDH 응용에서 사용되는 두번째 것은 반복적인 16개의 연속적인 J1 바이트 패턴을 찾는다. 3 연속 순간에 대해 일관된 16 바이트 패턴을 검출하였을 때, J1 패턴은 지정된 레지스터에 저장된다.

-- SONET J1 포착

IOS_RX_SDH_J1 = 0일 때 (SONET 모드), IOSL 디바이스는 경로 트레이스 메시지의 샘플을 포착하도록 제공될 수 있다. J1_CAP가 0에서 1로 전이될 때, IOSL 디바이스는 지정된 일부로부터 64개의 연속적인 J1 바이트를 포착하고, 이들을 IOS_RX_J1_[63:0]_[7:0]에 기록한다.

경로 트레이스 프레임 구조가 SONET에 대해 정의되지 않지만, GR-253은 64-바이트 시퀀스가 NULL 문자 (00)를 갖는 62 바이트로 패딩 (padding)되고 <CR> (0D) 및 <LF> (0A) 바이트로 종료된 ASCII 문자의 스트링으로 구성될 것을 추천한다. J1_CRLF 비트가 설정되면, IOSL 디바이스는 {0D, 0A}로 끝나는 J1 바이트 위치에서 수신한 제1 64 바이트 스트링을 포착한다. J1_CRLF 비트가 0이면, IOSL 디바이스는 그 내용에 관계없이 다음 64개의 J1 바이트를 포착한다. 포착이 완료되면, IOSL 디바이스는 J1_CAP_E 이벤트 비트를 설정한다.

-- 16-바이트 J1 모니터

IOS_RX_SDH_J1 = 1이면 (일반적으로 SDH 모드에서 사용되는), J1 바이트는 PAPI를 포함하는 반복적인 16-바이트 경로 트레이스 프레임을 포함할 것으로 기대된다. 이 모드에서, J1_CAP, J1_CRLF, 및 J1_CAP_E 비트는 사용되지 않는다. J1 모니터는 16-바이트 경로 트레이스 프레임의 시작에 고정되고, 3 연속 경로 트레이스 프레임에 대해 일관되게 정합되는 값에 대해 수신된 경로 트레이스 프레임을 조사하는 것으로 구성된다. 일관된 프레임 값이 수신될 때, 이는 IOS_RX_J1_[15:0]_[7:0]에 기록된다. 경로 트레이스 프레임의 제1 바이트 (프레임 시작 표시자를 포함하는)는 IOS_RX_J1_[15]_[7:0]에 기록된다.

프레임화. 경로 트레이스 프레임 바이트의 MSB는 프레임 시작 표시자 바이트의 MSB를 제외하고 모두 0이다. J1 모니터 프레이머는 MSB에 0을 갖고, MSB에 1을 갖는 J1 바이트로 이어지는 15개의 연속적인 J1 바이트를 탐색한다. 이 패턴이 발견될 때, 프레이머는 프레임, J1_OOF = 0으로 진행된다. 일단 J1 모니터 프레이머가 프레임내에 있으면, 이는 3개의 연속적인 경로 트레이스 프레임이 적어도 1 MSB 비트 에러를 갖고 수신될 때까지 프레임에 남아있다. (SONET 모드에서, J1 프레임 표시는 프레임내 상태, J1_OOF = 0에 유지된다.) J1_OOF_D 델타 비트는 J1_OOF가 상태를 변화시킬 때 설정된다.

패턴 수용 및 비교. 프레임에서 한번씩, J1 모니터 블록은 3개의 연속적인 16-바이트 경로 트레이스 프레임을 찾는다. 3개의 연속적인 동일 프레임이 수신될 때, 수용된 프레임은 IOS_RX_J1_[15:0]_[7:0]에 저장된다. 수용된 프레임은 이들 레지스터의 이전 내용에 비교된다. 새로운 값이 저장될 때는 RX_J1_D 델타 비트가 설정된다.

- BIP-8 (B3) 점검

IOSL 디바이스는 정확한 BIP-8 값에 대해 수신된 B3 바이트를 점검한다. 짝수 패리티 BIP-8은 각 프레임에서 SPE/VC (POH를 포함하는)의 모든 비트에 걸쳐 계산된다. 이들 값은 다음 프레임에서 수신된 B3 값에 비교된다. 비교 결과로 0 내지 8 부정합 (B3 비트 에러)이 주어질 수 있다. 이 값은 전송측 G1 바이트에 삽입될 수 있다.

IOSL 디바이스는 모든 B3 비트 에러 (BIT_BLKCNT = 0인 경우) 또는 적어도하나의 B3 비트 에러를 갖는 모든 프레임 (BIT_BLKCNT = 1인 경우)을 카운트하는 16-비트 B3 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이될 때), 이 카운터의 값은 B3ERRCNT_[15:0] 레지스터로 래치되고, B3 에러 카운터는 클리어된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 B3 에러가 있으면, B3 에러 제2 이벤트 비트, B3ERR_SECE가 설정된다.

- 신호 라벨 (C2) 모니터

수신된 C2 바이트는 정확한 종류의 페이로드의 수신이 확인될 수 있도록 모니터된다. 일관된 C2 값이 5개의 연속적인 프레임 동안 수신될 때, 수용된 값은 IOS_RX_C2[7:0]에 기록된다. IOS_RX_C2_D 델타 비트는 새로운 C2 값이 수용될 때 설정된다.

수신된 C2 바이트의 기대값은 EXP_C2[7:0]에 제공된다. 현재 수용값이 기대값과 정합되지 않고, 수용값이 다음과 같이 않으면,

* 모두 0인 비장착 라벨,

* 01 (hex) 장착-비특정 라벨

* FC (hex) 페이로드 결함 라벨

* FF (hex) 예정 라벨,

페이로드 라벨 부정합 레지스터 비트, IOS_RX_PLM은 고상태로 설정된다. 현재 수용값이 모두 0인 비장착 라벨이고, 제공된 EXP_C2[7:0]! = 00 (hex)이면, 비장착 레지스터 비트, IOS_RX_UNEQ은 고상태로 설정된다. IOS_RX_PLM 및IOX_RX_UNEQ 신호는 전송측에서 경로 RDI의 삽입에 기여한다. IOS_RX_PLM 또는 IOS_RX_UNEQ가 상태를 변화시키면, IOS_RX_PLM_D 또는 IOS_RX_UNEQ_D 델타 비트가 설정된다.

- 경로 상태 (G1) 모니터

-- 경로 REI 모니터

경로 상태 바이트의 비트 1 내지 4 (4 MSB)는 수신된 SPE/VC 신호에서 원격 단자에 의해 검출되었던 B3 에러의 수를 나타낸다. 0 내지 8 사이의 이진수값만이 적합하다. 8 보다 큰 값이 수신되면, 이는 0 에러로 해석된다 (GR-253 및 ITU-T 추천 G.707에서 지정된 바와 같이). IOSL 디바이스는 G1으로 나타내지는 모든 에러 (BIT_BLKCNT = 0인 경우) 또는 0과 같지 않은 G1의 처음 4 비트로 수신된 모든 프레임 (BIT_BLKCNT = 1인 경우)을 카운트하는 16-비트 G1 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이될 때), 이 카운터의 값은 G1_ERRCNT[15:0] 레지스터로 래치되고, G1 에러 카운터는 클리어된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 수신된 G1 에러 표시가 있으면, G1 에러 제1 이벤트 비트, G1ERR_SECE가 설정된다.

-- 경로 RDI 모니터

IOSL 디바이스는 IOS_RX_PRDI5 = 1인 경우 G1의 비트 5 (RDI-P 표시자); 또는 IOX_RX_PRDI5 = 0인 경우 G1의 비트 5, 6, 및 7을 모니터하도록 제공될수 있다. 모니터는 동일한 모니터 비트의 G1_CONSEC[3:0] 연속 수신값을 점검하는 것으로 구성된다. 일관된 값이 수신될 때, G1의 비트 5, 6, 및 7은 IOS_RX_G1[2:0]에 기록된다. 수용된 값은 이 레지스터의 이전 내용에 비교된다. (모두 3 비트가 기록되지만, IOX_RX_PRDI5 = 1이면, G1 비트 5 및 IOS_RX_G1[2]만이 비교에 포함된다.) 새로운 값이 저장될 때, IOS_RX_G1_D 델타 비트가 설정된다.

- 다른 POH 바이트

나머지 POH 바이트는 IOSL 디바이스에 의해 모니터되지 않는다. 이들은 경로 사용자 채널 (F2), 위치 표시자 (H4), 경로 성장/사용자 채널 (Z3/F3), 경로 성장/경로 APS 채널 (Z4/K3), 및 직렬 연결 모니터 (Z5/N1) 바이트를 포함한다.

수신 페이로드 디스크램블 처리

페이로드가 SONET/SDH 신호로부터 추출된 이후에, 페이로드 데이터는 자체 동기화 X⁴³+ 1 디스크램블러(29)를 사용하여 디스크램블 처리된다. 모든 모드에서, 레지스터 IOS_RX_DSCR_INH는 디스크램블러의 동작을 제어한다. IOS_RX_DSCR_INH = 0 (디폴트)일 때, 디스크램블러는 인에이블된다. IOS_RX_DSCR_INH = 1일 때, 디스크램블러의 동작은 금지된다. IOSL 디바이스는 다음 발생기 다항식: X⁴³+ 1을 근거로 자체 동기화 디스크램블러를 제공한다.

수신 LAPS 처리

이때는 SONET/SDH 프레임으로부터 SPE가 추출되고, 또 다른 처리를 위해 LAPS 프로세서에 전해진다. IOS 모드에서 (IOS_RX_POS = 1), LAPS 처리는 SPE로부터 LAPS 패킷/프레임을 추출한다.

- LAPS 디프레이머

LAPS 프레임은 프레임을 시작/종료하는 플래그 시퀀스(0x7e)를 식별함으로서 SPE 페이로드로부터 추출된다. IOSL 디바이스는 페이로드의 각 옥텟을 조사한다. 비트 패턴 0x7e를 갖는 옥텟이 발견될 때, IOSL 디바이스는 이것이 패킷의 시작/종료인 것으로 인식한다. 이어서, 이 플래그 시퀀스에 이어지는 옥텟이 조사된다. 이들이 또한 0x7e이면, 이는 패킷간 갭을 채우는데 사용되는 플래그 시퀀스이므로, 버려진다. 초기 플래그 시퀀스에 이어지는 0x7e와 같지 않은 제1 옥텟은 LAPS 프레임의 제1 옥텟인것으로 생각된다. 프레임 플래그의 시작 이후에, IOSL 디바이스는 플래그 시퀀스에 대한 페이로드의 각 옥텟을 계속하여 조사한다. 비트 패턴 0x7e의 위치를 알아내고 바로 선행되는 옥텟이 제어 탈출 (0x7d)이면, 그 프레임은 중지된다. 그렇지 않으면, 현재 프레임의 정상적인 종료가 선언된다. FCS 필드의 종료가 금지되는 특수한 경우에 (섹션 6.9.5를 참고), 프레임 사이에는 최소 2개의 플래그 시퀀스가 검출되어야 한다.

- 투명성 바이트 스터핑의 제거

IOSL 디바이스는 원래의 패킷 스트림을 회복하도록 투명성 바이트 스터핑 (stuffing) 처리를 전환한다. IOS_RX_POS_FIFOUNDR_MODE = 1이면, FIFO 언더플로우의 주기 동안 전송측에 의해 삽입될 수 있는 FIFO 언더플로우 바이트 시퀀스는 투명성 처리 동안 검출되어 제거된다. IOS_RX_IOS_FIFOUNDR_MODE = 0이면, 디폴트값이 디스에이블된다. 특수한 FIFO 바이트 코드는 레지스터 IOS_RX_IOS_FIFOUNDR_BYTE[7:0]을 사용하여 프로그램된다.

-- 언더플로우 바이트 제거

IOS 모드에서, IOS_RX_IOS_FIFOUNDR_MODE = 1이면, FIFO 언더플로우 바이트 코드(IOS_RX_IOS_FIFOUNDR_BYTE[7:0])와 정합되는 바이트는 제어 탈출 코드(0x7d)에 의해 바로 선택되지 않는 경우 버려진다.

- 에러가 있는 프레임

IOS 모드에서 (IOS_RX_IOS = 1), 특수 바이트 코드(0x7d7e)는 프레임이 중지되었음을 나타내도록 IOS 모드에서 사용된다. 이 바이트 코드가 수신되면, 이를 포함하는 프레임은 중지된다. 그 패킷으로부터의 옥텟이 더 이상 FIFO로 전달되지 않고, 패킷이 링크층 디바이스에 전송되면, 이는 에러가 있는 것으로 표시된다. IOSL 디바이스는 중지 시퀀스가 검출된 모든 패킷을 카운트하는 8-비트 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이), 이 카운터의 값은 IOS_RX_IOS_PABORT_ERRCNT[7:0] 레지스터로 래치되고, 패킷 중지 에러 카운터는 클리어된다.

LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 패킷 중지 에러가 있으면, 패킷 중지 에러 제2 이벤트 비트, IOS_RX_IOS_PABORT_ERR_SECE가 설정된다. 다른 방법으로, 패킷은 또한 FCS 바이트를 반전시킴으로서 중지될 수 있다. 이는 간단하게 FCS 에러로 IOSL 디바이스 수신 LAPS 프로세서에 나타나고, 다음 섹션에서 설명될 바와 같이 처리된다.

IOSL 디바이스는 또한 한 옵션으로 에러가 있는 패킷을 관찰하고, 이것이 최소 또는 최대 패킷 크기를 위반하는 경우 그에 따라 이를 표시한다. 패킷 크기는 단지 IOSL 디바이스로부터의 패킷 출력의 크기를 칭하고, 드롭 (drop)된 플래그 시퀀스, 어드레스, 제어, 투명성, FIFO 언더플로우, 및 FCS 바이트를 포함하지 않는다. 이들 최소 및 최대 크기는 관리 인터페이스를 통해 프로그램된다. 레지스터 IOS_RX_IOS_PMIN[3:0]은 최소 패킷 크기를 포함한다. 이 레지스터의 디폴트 값은 0이다. 레지스터 IOS_RX_IOS_PMAX[15:0]은 최대 패킷 크기를 포함한다. 이 레지스터의 디폴트 값은 0x05E0이다. IOSL 디바이스는 관리 인터페이스를 통해 지시될 때 최소 및 최대 크기 패킷 점검을 디스에이블/인에이블시킨다. 레지스터 IOS_RX_IOS_PMIN_ENB 및 IOS_RX_IOS_PMAX_ENB (모두 디폴트는 0)는 최소 및 최대 패킷 크기의 위반이 처리되는 방법을 제어한다. 1로 설정될 때, 대응하는 패킷 크기 제한의 위반은 에러가 있는 것으로 표시된다.

IOSL 디바이스는 최대 및 최소 패킷 크기 제한을 위반할 때마다 카운트하는 2개의 8-비트 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이), 이 카운터의 값은 IOS_RX_IOS_PMIN_ERRCNT[7:0] 및 IOS_RX_IOS_PMAX_ERRCNT[7:0] 레지스터에 래치되고, 패킷 크기 위반 카운터는 클리어된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 패킷 크기 위반 에러가 있으면, 적절한 패킷 크기 위반 제2 이벤트 비트, IOS_RX_IOS_PMIN_ERR_SECE 또는 IOS_RX_IOS_PMAX_ERR_SECE가 설정된다.

- 프레임 점검 시퀀스(FCS) 필드

IOS 모드에서 (IOS_RX_IOS = 1), FCS는 각 프레임의 끝에 있는 FCS에 대해 계산되어 점검된다. 이 옵션은 레지스터 IOS_RX_IOS_FCS_INH에 의해 제어된다. IOS_RX_IOS_FCS_INH = 0의 값은 FCS를 인에이블시킨다. IOS_RX_IOS_FCS_INH = 1의값은 이를 디스에이블시키고, 32 비트 점검 시퀀스(CRC-32)만이 적용된다. IOS_RX_IOS_FCS_MODE = 0이면, 디바이스는 FCS-32 모드에 놓인다. IOSL 디바이스는 다음의 발생기 다항식을 사용하여 CRC-32 기능을 제공한다:

1 + x + x²+ x⁴+ x⁵+ x⁷+x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+ x²³+ x²⁶+ x³²

FCS 필드는 플래그 시퀀스 및 FCS 필드 자체를 제외하고 모든 비트 프레임에 걸쳐 계산된다. IOS_RX_IOS_FCS_BIT_ORDR = 0 (디폴트)이면, 수신된 데이터는 큰 엔디언 (endian) 비트 순서로 (MSB가 첫번째) 쉬프트 레지스터에 판독된다. IOS_RX_IOS_FCS_BIT_ORDR = 1이면, 수신된 데이터는 작은 엔디언 비트 순서로 (LSB가 첫번째) 쉬프트 레지스터에 판독된다. 어떠한 경우에서든, 데이터는 FCS 계산 이후 처리를 위해 큰 엔디언 순서로 재저장된다.

결과의 FCS는 수신된 FCS 필드내의 값과 비교된다. 에러가 검출되면, 관리 제어 인터페이스에 알려져 적절한 카운터가 증가되고, 패킷의 최종 워드는 FIFO에서 에러가 있는 것으로 표시된다. IOSL 디바이스는 FCS CRC 위반을 모두 카운트하는 20-비트 FCS 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이), 이 카운터의 값은 IOS_RX_IOS_FCS_ERRCNT[19:0] 레지스터에 래치되고, FCS 에러 카운터가 클리어된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 FCS 에러가 있으면, FCS 에러 제2 이벤트 비트, IOS_RX_IOS_FCS_ERR_SECE가 설정된다. FCS 점검에 이어서, FCS 바이트는 종료된다 (이들은 FIFO에 저장되지 않는다). FCS 점검이 관리 인터페이스를 통해 디스에이블되면, 마지막 2 또는 4 바이트는 FIFO로 전달된다. FCS 에러가 검출되면, 패킷은 링크층 디바이스로 전송될 때 에러가 있는 것으로 표시된다 (RX_ERR).

- LAPS 프레임 종료

IOS 모드에서 (IOS_RX_IOS = 1), FCS 계산 이후, 다음의 LAPS 바이트는 모니터되어 선택적으로 종료된다:

-- 플래그 시퀀스

프레임을 서술하고 프레임 간을 채울 목적으로 사용된 모든 플래그 시퀀스는 삭제된다. 프레임 정보의 시작 및 종료는 IOSL 디바이스에 의해 유지되고, RX_SOP 및 RX_EOP 신호를 통해 링크층에 전송된다.

-- 어드레스 및 제어 바이트

어드레스 및 제어 바이트 (플래그 시퀀스에 이어지는 LAPS 프레임 중 처음 2 바이트)는 IOSL 디바이스에 의해 모니터된다. 모니터는 유효한 어드레스 및 제어 필드(0xFF03)를 점검하는 것으로 구성된다. 정합이 검출되지 않으면, 이 필드는 압축된 것으로 가정되어 전달되지 않는다. 유효하지 않은 값이 검출되면, 이들 두 바이트는 드롭되지 않고, IOS 인터페이스를 통해 링크층에 전해진다. 관리 제어 인터페이스에는 IOS_RX_IOS_ADRCTL_INVALID = 1을 설정함으로서 유효하지 않은 어드레스 및 제어 필드의 검출이 통보된다. ISO_RX_IOS_ADRCTL_INVALID의 상태 변화는 대응하는 델타 비트 IOS_RX_IOS_ADRCTL_INVALID_D를 1로 설정함으로서 나타내진다. 유효한 어드레스 및 제어 필드(0xFF03)가 검출되면, IOSL 디바이스는 2개의 바이트를 종료하고, 이들을 RX FIFO에 전달하지 않는다. 유효한 어드레스 및 제어바이트의 검출은 IOS_RX_IOS_ADRCTL_DROP_INH = 1을 설정함으로서 금지될 수 있다. 이 레지스터의 디폴트 값은 0이다 (자동 드롭 인에이블).

-- FCS 바이트

FCS 섹션에서 기술된 바와 같이, 4개의 FCS 바이트는 또한 IOSL 디바이스로 종결된다. FCS 점검이 관리 제어 인터페이스를 통해 디스에이블되면 (IOS_RX_IOS_FCS_INH = 1), 이 종결도 또한 디스에이블되고, LAPS 프레임에서 최종 4개의 바이트가 링크층으로 전달되다.

수신 FIFO 인터페이스

- 시스템측 패킷 루프백

IOSL 디바이스는 사용자가 시스템 인터페이스를 통해 수신된 패킷을 루프백하는 기능을 제공한다. SYS_T_TO_R_LOOP = 1일 때, 링크층 디바이스로부터 수신된 패킷은 전송 FIFO에서 직접 수신 FIFO로 전해지고, 셀 데이터를 처음 제공했던 링크층 디바이스로 다시 출력한다. SYS_T_TO_R_LOOP가 0으로 설정될 때, SONET/SDH 라인 신호내에서 수신된 패킷 데이터는 수신 FIFO로 전송되고, 이어서 시스템 인터페이스로 전송된다.

- FIFO 처리

IOSL 디바이스는 수신 시스템 인터페이스를 통해 링크층 디바이스로 출력하도록 FIFO에 패킷 데이터를 기록한다. FIFO는 256개의 옥텟을 유지한다. 패킷과 함께, 다음 표시자는 적용가능할 때 FIFO내의 각 워드를 수반하여야 한다: 패킷의 시작, 패킷의 종료, 패킷의 종료인 경우, 얼마나 많은 패킷이 워드에 있는가 (1 또는 2), 또는 패킷에 에러가 있는가 여부. 일단 에러가 패킷에서 검출되면, 그 패킷으로부터는 더 이상 바이트가 FIFO로 로드(load)되지 않는다. FIFO의 상태는 IOSL 디바이스에 의해 모니터된다. FIFO 오버플로우 이벤트는 IOS_RX_FIFOOVER_E = 1을 설정함으로서 관리 제어 인터페이스에 보고된다. FIFO 오버플로우의 발생은 또한 적절한 성능 모니터 카운터를 증가시킨다.

IOSL 디바이스는 FIFO 오버플로우 이벤트에 의해 영향을 받는 모든 패킷을 카운트하는 8-비트 FIFO 오버플로우 에러 카운터를 포함한다. 성능 모니터 카운터가 래치될 때 (LATCH_EVENT가 고상태로 전이), 이 카운터의 값은 IOS_RX_FIFOOVER_ERRCNT[7:0] 레지스터에 래치되고, FIFO 오버플로우 에러 카운터는 클리어된다. LATCH_EVENT의 최종 상승 엣지 이래로 적어도 하나의 FIFO 오버플로우 이벤트가 있으면, FIFO 오버플로우 에러 이벤트 비트, IOS_RX_FIFOOVER_ERR_SECE가 설정된다. 일단 오버플로우 에러가 검출되면, 그 패킷으로부터는 더 이상 패킷이 FIFO에 전해지지 않는다. IOS 모드에서 (IOS_RX_IOS = 1), 패킷의 최종 워드는 에러가 있는 것으로 표시된다 (RX_ERR). FIFO는 즉시 수신 시스템 호환 인터페이스로 진행된다. 그 목적은 SONET 클럭 정의역과 링크층 클럭 정의역 사이에 비율 정합 기능을 실행하는 것이다.

-- 에러가 있는 패킷 처리

IOS 모드에서 (IOS_RX_IOS = 1), IOSL 디바이스는 RX_ERR을 사용하여 FIFO 오버플로우 이벤트에 의해 변형된 패킷을 에러가 있는 것으로 표시한다.

유효하지 않은 프레임은 다음과 같은 프레임이다:

a) 2 플래그에 의해 적절하게 경계가 지워지지 않는 프레임; 또는

b) 프레임의 플래그 사이에 8개 이하의 옥텟을 갖는 프레임; 또는

c) 프레임 점검 순차 에러를 포함하는 프레임; 또는

d) 수신기에 의해 지지되지 않거나 부정합된 서비스 억세스점 식별자 (ITU-T X.85의 A.3.3을 참고)를 포함하는 프레임; 또는

e) 인식되지 않은 제어 필드값을 포함하는 프레임; 또는

f) 6 이상의 "1" 비트의 시퀀스로 끝나는 프레임.

유효하지 않은 프레임은 전달자에게 통보하지 않고 버려진다. 그 프레임의 결과로, 아무런 작용도 취해지지 않는다.

-- 수신 데이터 패리티

MAC-PHY 조건서에 따라, IOSL 디바이스는 링크층 디바이스에 전송되는 1 또는 2 옥텟 워드(IOS_RX_SYS_DAT[15:0])를 각각 동반하는 패리티 점검 비트를 제공한다. 이 패리티 점검 비트는 핀 RX_PRTY에 주어진다. 이 비트는 홀수 패리티 점검을 디폴트로 (IOS_RX_PRTY_MODE = 0) 제공한다. 짝수 패리티는 IOS_RX_PRTY_MODE = 1인 경우 제공된다.

관리 제어 인터페이스

이후에는 IOSL 디바이스에 대한 관리 제어 인터페이스를 설명하고, 외부 마이크로프로세서에 의해 기록 또는 판독하는데 이용가능한 모든 레지스터의 어드레스를 정의한다.

마이크로프로세서 버스 어드레스 ADDR[8:0]의 MSB는 맵 (map)이 전송(ADDR[8] = 0) 또는 수신 (ADDR[8] = 1) 방향과 연관되는가 여부를 나타낸다. ADDR[7:0]은 특정한 맵을 나타내고, 그 값들은 이어지는 각 맵의 상세한 설명으로 식별된다. 공통된 구성 및 상태 맵은 ADDR[8] = 0을 갖는다.

인터럽트 또는 폴링 (polling)된 동작

관리 제어 인터페이스는 인터럽트 구동 또는 폴링된 모드로 동작될 수 있다. 두 모드에서, 공통된 구성 및 요약된 상태 맵의 어드레스 0x002내의 IOSL 디바이스 레지스터 비트 SUM_INT는 IOSL 디바이스에서 모니터 레지스터의 상태에 변화가 일어났는가 여부를 결정하는데 사용될 수 있다.

- 인터럽트 소스

-- 전송측

전송측 레지스터 맵은 거의 전체적으로 SONET/SDH 신호의 구성을 결정하고 LAPS, SONET/SDH POH, 및 SONET/SDH TOH/SOH 값을 제공하는 매개변수를 제공한다. 이들 제공 매개변수에 부가하여, 전송측 레지스터 맵은 시스템 인터페이스 및 범용 I/O 모니터를 포함한다. 이들 표시가 활성화 상태이면, 레지스터 0x002의 SUM_INT 비트는 고상태 (논리 1)가 된다. SUM_INT_MASK = 0이면, 마이크로프로세서 인터페이스에 대한 인터럽트 출력, INTB는 활성화 상태 (논리 0)가 된다.

-- 수신측

테이블 (TBD)은 또한 수신측에 대한 요약 상태 비트를 레지스터 0x005에 포함한다. 이들 비트는 레지스터 0x002에서 SUM_INT 비트에 기여한다. 임의의 요약 상태 비트가 "1"이고 대응하는 마스크 비트가 "0"이면, SUM_INT 비트는 "1"로 설정된다. 테이블 (TBD)에서 하나 이상의 대응하는 비트 그룹이 "1"이면, 테이블 (TBD)의 레지스터 0x005에서 요약 상태 비트는 "1"이다. 각 TOH/SOH 델타 및 제2 이벤트 비트는 표시될 수 있다 (테이블 (TBD), 어드레스 0x104-0x106).

- 인터럽트 구동

인터럽트 구동 모드에서, 공통 구성 및 요약 상태 맵의 레지스터 0x006에서 SUM_INT_MASK 비트는 클리어되어야 한다 (논리 0). 이는 INTB 출력이 활성화 되도록 (논리 0) 허용한다. 이 출력은 INTB = !(!SUM_INT_MASK && SUM_INT)이다. 부가하여, 수신측의 MII_RX_APS_INT_MASK 비트는 클리어되어야 한다 (논리 0). 이는 APS_INTB 출력이 활성화 되도록 (논리 0) 허용한다. 이 출력은 APS_INTB = !(!MII_RX_APS_INT_MASK && MII_RX_APS_INT)이다.

인터럽트가 발생되면, 마이스크로프세서는 먼저 활성화 상태인 인터럽트 소스의 클래스(class)를 결정하도록 요약 상태 레지스터, 0x004-0x005를 판독하고, 이어서 인터럽트의 정확한 원인을 결정하도록 그 클래스 내의 특정 레지스터를 판독할 수 있다.

- 폴링 모드

SUM_INT_MASK 및 MII_RX_APS_INT_MASK 비트는 모든 하드웨어 인터럽트를 억제하고 폴링 모드에서 동작하도록 설정되어야 한다 (논리 1). 이 모드에서, IOSL 디바이스는 INTB를 출력하고, APS_INTB는 비활성화(논리 1) 상태로 유지된다. SUM_INT_MASK 및 MII_RX_APS_INT_MASK 비트는 레지스터 비트 SUM_INT 및 MII_RX_APS_INT의 상태에 영향을 주지 않는다. 이들 비트는 레지스터 질문이 더필요한가를 결정하도록 폴링될 수 있다.

마이크로프로세서 인터페이스

마이크로프로세서 인터페이스는 IOSL 디바이스를 시스템 CPU로 인터페이스 연결시킨다. 마이크로프로세서 인터페이스는 시스템 CPU가 IOSL 디바이스내의 모든 레지스터에 억세스할 수 있게 한다. 마이크로프로세서 인터페이스는 인터럽트 구동 모드 또는 폴링 모드로 동작할 수 있다. 인터럽트 모드에서, IOSL 디바이스는 다수의 인터럽트 소스를 지지할 수 있다. IOSL 디바이스는 인터럽트 모드에서 임의의 인터럽트에서 벗어날 수 있다.

구형의 SDH/SONET를 통한 PPP 디바이스와의 호환가능성

도 10에서는 본 발명과 RFC 2615의 프레임 포맷이 비교된다. 도 10에 도시된 바와 같이, SAPI가 255로 설정되면, LAPS 프레임의 포맷은 PPP/HDLC와 거의 동일하므로, PPP 패킷은 LAPS 프레이머/디프레이머를 사용하여 SDH를 통한 IP의 구성을 변화시키지 않고, 본 발명의 데이터 전송 장치에 의해 처리되고, 추출된 PPP 패킷은 PPP 처리를 위해 네트워크층으로 전송된다.

도 11은 본 발명에 따른 SDH를 통한 IP 설계를 사용하는 네트워크 상호연결의 한 예로, 여기서 실선은 노드 사이의 SDH 물리적 연결을 나타내고, 점선은 노드 사이의 제안된 패킷 교환을 나타낸다. 검은색 노드는 게이트웨이로 동작하는 네트워크의 엣지에 있는 노드를 나타내고, 흰색 노드는 노드의 시점으로부터 SDH를 통한 IP 네트워크를 관찰할 수 있는 네트워크의 백본 (backbone) 노드를 나타낸다. SDH를 통한 IP에서, 똑같은 링크의 단 2개의 피어 (peer) 물리적 인터페이스가 똑같은 인터페이스 비율 및 물리적 매개변수를 가지면, 네트워크의 링크에 다른 비율의 다양한 SDH를 통한 IP 물리적 인터페이스가 있을 수 있음이 강조된다.

본 발명의 SAPI 값은 네트워크층 또는 상단층으로부터 수신된 데이터의 종료에 따라 변할 수 있고, 이는 Ipv4, Ipv6, PPP, IS-IS, 에테르넷, 또는 다른 종류의 데이터를 수용할 수 있다. 예를 들면, MPEG 데이터 전송에서, SAPI는 값 "64" 또는 "128"로 지정될 수 있다. 본 발명의 설계는 IP를 SDH/SONET, 간략화된 SDH에 적응하는데, 또는 IP를 SDH, 이어서 WDM나 PEH (pseudo SDH)에 적응하는데 사용될 수 있다. PEH의 경우, LAPS 프레임에서 캡슐화된 정보 필드는 옥텟 지향적인 대신에 비트 지향적이다.

상기 설명으로부터, 본 발명은 코어 및 엣지 라우터(core and edge router), 스위치 디바이스, IP 근거의 네트워크 억세스 장비, 라인 카드(line card), 및 고속으로 사용되는 인터페이스 유닛, 예를 들면 IP를 SDH/SONET에 직접 적응하기 위한 기가비트(Gigabit) 응용에 적용될 수 있는 새로운 데이터 전송 장치 및 방법을 설명함을 알 수 있다. 본 발명은 간단하고, 효과적이고, 확실하고, 저비용이고, 또한 고속 데이터 전송 응용, 특별히 엣지 네트워크 노드 응용에 적절한 이점을 갖는다. 본 발명의 장치 또는 라우터는 SDH를 통한 PPP 라인 카드 또는 라우터와 같이, 구형 장비와 호환가능하도록 쉽게 구성될 수 있다.

바람직한 실시예에서 본 발명의 원리를 설명하고 도시하였지만, 본 발명은 본 발명의 의도 및 범위에서 벗어나지 않고 배열 및 상세한 내용에서 수정될 수 있음이 명백하다. 예를 들면, SDH 및 SONET 이외에, 전송 및/또는 수신 방향의 데이터 전송 장치 및 방법은 간략화된 SDH, 의사-SDH (pseudo-SDH), WDM, 에테르넷 (Ethernet)과 같은 다른 물리층 디바이스에 적용되고, 다른 네트워크층 프로토콜을 수용할 수 있다. 이러한 수정 및 변형은 모두 첨부된 청구항에서 정의된 범위내에 포함되어야 한다.

Claims

네트워크층측 디바이스로부터 물리층측 디바이스로 데이터 패킷(data packet)을 전송하는 데이터 전송 장치에 있어서,

상기 네트워크층측 디바이스로부터 특정한 종류의 데이터 패킷을 수신하는 제1 수신 수단;

상기 데이터 패킷의 종류를 인식하고 인식된 종류에 따라 SAPI 식별자를 발생하는 SAPI 식별자 발생 수단;

제1 타입의 프레임(frame)을 형성하도록 시작 플래그(flag), 상기 SAPI 식별자를 포함하는 SAPI 필드(field), 제어 필드, 상기 데이터 패킷을 포함하는 정보 필드, FCS 필드, 및 종료 플래그의 포맷으로 상기 데이터를 캡슐화(encapsulate)하는 제1 프레임화(framing) 수단;

제2 타입의 프레임을 형성하도록 상기 제1 타입의 프레임을 페이로드(payload) 부분으로 캡슐화하고, 적절한 오버헤드(overhead)를 삽입하는 제2 프레임화 수단; 및

상기 제2 타입의 프레임을 상기 물리층측 디바이스에 출력하는 제1 전송 수단

을 포함하는 것을 특징으로 하는 데이터 전송 장치.
제1항에 있어서,

X⁴³+ 1 스크램블(scramble) 처리를 실행하는 자체-동기화 스크램블 처리 수단을 더 포함하고, 상기 스크램블 처리 수단은 XOR 게이트 및 43-비트 쉬프트 레지스터(shift register)를 포함하고, 출력 비트는 생(raw) 입력 데이터 비트와 XOR 처리되어 전송 비트를 만드는 것을 특징으로 하는 데이터 전송 장치.
제2항에 있어서,

상기 제1 타입의 프레임에서 상기 페이로드 부분의 시작 위치를 나타내는 포인터(pointer)를 삽입하는 포인터 삽입 수단을 더 포함하는 것을 특징으로 하는 데이터 전송 장치.
제3항에 있어서,

상기 제1 수신 수단은 입력 데이터 패킷을 수신하여 버퍼(buffer) 처리하는 제1 FIFO인 것을 특징으로 하는 데이터 전송 장치.
제4항에 있어서,

상기 시작 플래그 및 종료 플래그는 "0x7E"인 것을 특징으로 하는 데이터 전송 장치.
제5항에 있어서,

상기 제1 프레임화 수단은 프레임 사이를 채우는 동작을 실행하는 것을 특징으로 하는 데이터 전송 장치.
제6항에 있어서,

상기 제1 프레임화 수단은 0x7E를 0x7D, 0x5E로 또한 0x7D를 0x7D, 0x5D로 부호화하는 투명성 처리(옥텟 스터핑 (octet stuffing))를 실행하는 것을 특징으로 하는 데이터 전송 장치.
제7항에 있어서,

상기 제1 프레임화 수단은 발생기 다항식(generating polynomial): 1 + x + x²+ x⁴+ x⁵+ x⁷+ x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+x²³+ x²⁶+ x³²에 의해, 상기 시작 플래그, 종료 플래그, 및 FCS 필드 자체를 제외하고 프레임내의 모든 옥텟에 걸쳐 32 비트 프레임 점검 시퀀스 필드를 계산하는 것을 특징으로 하는 데이터 전송 장치.
제8항에 있어서,

상기 페이로드 부분은 상기 제1 타입의 프레임을 운반하는 다수의 페이로드 서브부분을 포함하고, 상기 제1 타입의 프레임의 경계는 상기 페이로드 부분의 경계와 정렬되는 것을 특징으로 하는 데이터 전송 장치.
제4항에 있어서,

상기 SAPI 발생 수단은 상기 제1 FIFO로부터 상기 SAPI를 구하는 것을 특징으로 하는 데이터 전송 장치.
제9항에 있어서,

상기 SAPI 발생 수단은 상기 제1 FIFO로부터 상기 SAPI를 구하는 것을 특징으로 하는 데이터 전송 장치.
제1항에 있어서,

이전 프레임의 종료 플래그는 상기 이전 프레임 다음에 이어지는 프레임의 시작 플래그인 것을 특징으로 하는 데이터 전송 장치.
제1항에 있어서,

미리 설정된 최소 패킷 크기 (minimum packet size, mPS) 및 최대 패킷 크기 (maximum packet size, MPS)로, 입력 패킷이 상기 MPS 보다 더 길거나 상기 mPS 보다 더 짧으면, 에러 표시를 발생하는 패킷 크기 처리 수단을 더 포함하는 것을 특징으로 하는 데이터 전송 장치.
제1항에 있어서,

상기 제2 프레임으로부터 추출된 상기 제1 타입의 프레임을 테스트를 위해 상기 제1 FIFO로 루프백 (loopback)하는 라인측 패킷 루프백 수단을 더 포함하는 것을 특징으로 하는 데이터 전송 장치.
제1항 내지 제14항 중 어느 한 항에 있어서,

상기 물리층은 SDH/SONET, 간략화된 SDH/SONET, 의사-동기화 디지털 계층구조 (pseudo-synchronous digital hierachy), 및 WDM 중 하나인 것을 특징으로 하는 데이터 전송 장치.
제1항 내지 제15항 중 어느 한 항에 있어서,

네트워크층으로부터의 상기 데이터 패킷은 Ipv4, Ipv6, IS-IS, PPP 패킷, 또는 MPEG 데이터 스트림으로, 각각이 소정의 SAPI 값에 각각 대응하고, 상기 제1 타입의 프레임은 LAPS 프레임이고, 또한 상기 제2 타입의 프레임은 SDH/SONET형 프레임인 것을 특징으로 하는 데이터 전송 장치.
제9항에 있어서,

상기 페이로드 부분은 SDH/SONET에 대한 SPE이고, 상기 페이로드의 서브 부분은 가상 컨테이너 (virtual container)인 것을 특징으로 하는 데이터 전송 장치.
제16항에 있어서,

DS 코드점은 대기열 (queue) 알고리즘을 제어하도록 네트워크층 데이터로부터 추출되는 것을 특징으로 하는 데이터 전송 장치.
제1 타입의 프레임을 적절한 오버헤드를 갖는 페이로드로서 제2 타입의 프레임에 캡슐화함으로서 형성된 데이터 패킷을 물리층측 디바이스에서 네트워크층측 디바이스로 전송하는 - 상기 제1 타입의 프레임은 각각 시작 플래그, 어드레스 필드, 제어 필드, 정보 필드, FCS 필드, 및 종료 필드를 포함함 - 데이터 전송 장치에 있어서,

상기 물리층측 디바이스로부터 데이터 패킷을 수신하는 제2 수신 수단;

상기 오버헤드를 제거하고, 상기 제2 타입의 프레임의 페이로드로부터 상기 제1 타입의 프레임을 추출하는 제2 역프레임화(de-framing) 수단;

상기 제1 타입의 프레임으로부터 정보 필드에 포함된 데이터 및 어드레스 필드를 추출하는 제1 역프레임화 수단;

적어도 제1 값 및 제2 값을 포함하는 미리 설정된 값의 세트와 상기 어드레스 필드(SAPI 필드)의 값을 비교하고, 상기 어드레스 필드 데이터의 값이 상기 제1 값과 정합되면, 추출된 데이터가 제1 타입인 것으로 결정하고, 상기 어드레스 필드의 값이 상기 제2 값과 정합하면, 추출된 데이터가 제2 타입인 것으로 결정하는 결정 수단; 및

추출된 데이터 패킷과 결정 결과를 상기 네트워크층측 디바이스에 전송하는 제2 전송 수단

을 포함하는 것을 특징으로 하는 데이터 전송 장치.
제19항에 있어서,

X⁴³+ 1 디스크램블 (descramble) 처리를 실행하는 디스크램블 처리 수단을 더 포함하고, 상기 디스크램블 처리 수단은 XOR 게이트 및 43-비트 쉬프트 레지스터를 포함하고, 출력 비트는 스크램블 처리된 입력 데이터 비트와 XOR 처리되어 스크램블 처리되지 않은 비트를 만드는 것을 특징으로 하는 데이터 전송 장치.
제20항에 있어서,

포인터로 나타내지는 상기 제2 타입의 프레임에 캡슐화하는 상기 제1 타입의 프레임의 시작 위치를 나타내는 포인터 해석 수단을 더 포함하는 것을 특징으로 하는 데이터 전송 장치.
제21항에 있어서,

상기 제2 전송 수단은 추출된 데이터 패킷을 수신하여 버퍼 처리하는 제2 FIFO인 것을 특징으로 하는 데이터 전송 장치.
제22항에 있어서,

상기 시작 플래그 및 종료 플래그는 "0x7E"인 것을 특징으로 하는 데이터 전송 장치.
제23항에 있어서,

상기 제1 역프레임화 수단은 프레임 사이를 채운 것을 제거하는 것을 특징으로 하는 데이터 전송 장치.
제24항에 있어서,

상기 제1 역프레임화 수단은 0x7D, 0x5E를 0x7D로 또한 0x7D, 0x5D를 0x7D로 복호화하기 위해 디스터핑 (destuffing) 과정을 실행하는 것을 특징으로 하는 데이터 전송 장치.
제25항에 있어서,

수신된 FCS 필드는 발생기 다항식: 1 + x + x²+ x⁴+ x⁵+ x⁷+ x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+x²³+ x²⁶+ x³²에 의해, 시작 플래그와 종료 플래그 사이의 모든 옥텟에 걸쳐 FCS 점검합 (checksum)을 계산함으로서 검증되는 것을 특징으로 하는 데이터 전송 장치.
제26항에 있어서,

상기 추출된 SAPI 값은 상기 제2 FIFO에 저장되는 것을 특징으로 하는 데이터 전송 장치.
제29항에 있어서,

이전 프레임의 종료 플래그는 상기 이전 프레임 다음에 이어지는 프레임의 시작 플래그인 것을 특징으로 하는 데이터 전송 장치.
제30항에 있어서,

상기 제2 FIFO는 미리 설정된 최소 패킷 크기 (mPS) 및 최대 패킷 크기 (MPS)를 갖고, 입력 패킷이 상기 MPS 보다 더 길거나 상기 mPS 보다 더 짧으면, 에러 표시를 발생하는 것을 특징으로 하는 데이터 전송 장치.
제19항 내지 제29항 중 한 항에 있어서,

상기 물리층은 SDH/SONET, 간략화된 SDH/SONET, 의사-SDH (pseudo-SDH), 및 WDM 중 하나인 것을 특징으로 하는 데이터 전송 장치.
제19항 내지 제30항 중 한 항에 있어서,

상기 제1 타입의 프레임은 LAPS 프레임이고, 상기 제2 타입의 프레임은 SDH/SONET형 프레임이고, 상기 그로부터 추출된 데이터 패킷은 Ipv4, Ipv6, IS-IS, PPP 패킷, 또는 MPEG 데이터 스트림인 것을 특징으로 하는 데이터 전송 장치.
제31항에 있어서,

연결 관리 유닛을 더 포함하고, 상기 연결 관리 유닛은 수신된 프레임이 없는 주기가 미리 설정된 시간을 넘는가를 모니터하는 타이머, 및 상기 타이머의 만기 시간을 카운트하는 카운터를 포함하고, 상기 카운터가 미리 설정된 값까지 카운트되면, 상기 연결 관리 유닛은 연결 에러가 있는 것으로 결정하여, 글로벌 라우팅 엔진(global routing engine)내의 네트워크 관리 엔터티(entity)에 보고하는 것을 특징으로 하는 데이터 전송 장치.
제32항에 있어서,

상기 타이머의 미리 설정된 시간은 1초에 설정되고, 상기 카운터의 미리 설정된 카운트 값은 3에 디폴트(default)로 설정되는 것을 특징으로 하는 데이터 전송 장치.
제1항 내지 제18항 중 한 항에 따른 데이터 전송 장치 및 제19항 내지 제33항 중 한 항에 따른 데이터 전송 장치를 구비하여, 네트워크층측 디바이스와 물리층측 디바이스 사이에 데이터 패킷을 전송하는 것을 특징으로 하는 데이터 전송 장치.
제34항에 있어서,

상기 제1 프레임화/역프레임화 수단에 포함된 처리를 실행하는 삽입된 CPU를더 포함하는 것을 특징으로 하는 데이터 전송 장치.
제37항에 있어서,

네트워크층 프로세서를 더 포함하고, 상기 네트워크층 프로세서는 SAPI가 255와 같다고-수신된 패킷이 PPP 패킷이고 더 처리될 필요가 있음을 나타냄- 상기 결정 수단이 결정할 때, PPP (LCP, NCP) 처리를 실행하거나 상기 제2 FIFO로부터 전송된 데이터 상에서 PPP 패킷을 글로벌 라우팅 엔진에 전달하는 PPP 처리 유닛을 포함하는 것을 특징으로 하는 데이터 전송 장치.
다수의 라인 카드(line card)를 포함하고, 상기 라인 카드 중 적어도 하나는 제1항 내지 제18항 중 한 항에 따른 데이터 전송 장치 및 제19항 내지 제33항 중 한 항에 따른 데이터 전송 장치를 포함하는 것을 특징으로 하는 라우터(router) 디바이스.
제37항에 있어서,

상기 적어도 하나의 라인 카드는 상기 제1 프레임화/역프레임화 수단에 포함된 처리를 실행하는 삽입된 CPU를 더 포함하는 것을 특징으로 하는 라우터 디바이스.
제38항에 있어서,

상기 적어도 하나의 라인 카드는 네트워크층 프로세서를 더 포함하고, 상기 네트워크층 프로세서는 SAPI가 255와 같다고-수신된 패킷이 PPP 패킷이고 더 처리될 필요가 있음을 나타냄- 상기 결정 수단이 결정할 때, PPP (LCP, NCP) 처리를 실행하거나 상기 제2 FIFO로부터 전송된 데이터 상에서 PPP 패킷을 글로벌 라우팅 엔진에 전달하는 PPP 처리 유닛을 포함하는 것을 특징으로 하는 라우터 디바이스.
제39항에 있어서,

각 라인 카드에 라우팅 엔진 및 네트워크 관리 모두를 위한 글로벌 CPU를 더 포함하는 것을 특징으로 하는 라우터 디바이스.
네트워크층측 디바이스로부터 물리층측 디바이스로 데이터 패킷을 전송하는 데이터 전송 방법에 있어서,

상기 네트워크층측 디바이스로부터 특정한 종류의 데이터 패킷을 수신하는 단계;

상기 데이터 패킷의 종류를 인식하고 인식된 종류에 따라 SAPI 식별자를 발생하는 단계;

제1 타입의 프레임을 형성하도록 시작 플래그, 상기 SAPI 식별자를 포함하는 SAPI 필드, 제어 필드, 상기 데이터 패킷을 포함하는 정보 필드, FCS 필드, 및 종료 플래그의 포맷으로 상기 데이터를 캡슐화하는 제1 프레임화 단계;

제2 타입의 프레임을 형성하도록 상기 제1 타입의 프레임을 페이로드 부분내로 캡슐화하고, 적절한 오버헤드를 삽입하는 제2 프레임화 단계; 및

상기 제2 타입의 프레임을 상기 물리층측 디바이스에 출력하는 단계

를 포함하는 것을 특징으로 하는 데이터 전송 방법.
제41항에 있어서,

전송된 상기 제1 타입의 프레임에 X⁴³+ 1 스크램블 처리를 실행하는 자체-동기화 스크램블 처리 단계를 더 포함하는 것을 특징으로 하는 데이터 전송 방법.
제42항에 있어서,

상기 시작 플래그 및 종료 플래그는 "0x7E"인 것을 특징으로 하는 데이터 전송 방법.
제43항에 있어서,

상기 제1 프레임화 단계에서는 프레임 사이를 채우는 동작이 실행되고, FIFO 에러 회복이 전송되는 것을 특징으로 하는 데이터 전송 방법.
제44항에 있어서,

상기 제1 프레임화 단계는 0x7E를 0x7D, 0x5E로 또한 0x7D를 0x7D, 0x5D로 부호화하는 투명성 처리(옥텟 스터핑)를 실행하는 것을 특징으로 하는 데이터 전송방법.
제45항에 있어서,

상기 제1 프레임화 단계는 발생기 다항식: 1 + x + x²+ x⁴+ x⁵+ x⁷+ x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+x²³+ x²⁶+ x³²에 의해, 상기 시작 플래그, 종료 플래그, 및 FCS 필드 자체를 제외하고 프레임내의 모든 옥텟에 걸쳐 32 비트 프레임 점검 시퀀스 필드를 계산하는 것을 특징으로 하는 데이터 전송 방법.
제46항에 있어서,

이전 프레임의 종료 플래그는 상기 이전 프레임 다음에 이어지는 프레임의 시작 플래그인 것을 특징으로 하는 데이터 전송 방법.
제47항에 있어서,

상기 입력 데이터 패킷은 처리되기 이전에 비율 적응을 위해 버퍼 처리되는 것을 특징으로 하는 데이터 전송 방법.
제41항 내지 제48항 중 한 항에 있어서,

상기 물리층은 SDH/SONET, 간략화된 SDH/SONET, 의사-동기화 디지털 계층구조, 및 WDM 중 하나인 것을 특징으로 하는 데이터 전송 방법.
제41항 내지 제49항 중 한 항에 있어서,

네트워크층으로부터의 상기 데이터 패킷은 Ipv4, Ipv6, IS-IS, PPP 패킷, 또는 MPEG 데이터 스트림으로서, 각각이 소정의 SAPI 값에 각각 대응하고, 상기 제1 타입의 프레임은 LAPS 프레임이고, 또한 상기 제2 타입의 프레임은 SDH/SONET형 프레임인 것을 특징으로 하는 데이터 전송 방법.
제1 타입의 프레임을 적절한 오버헤드를 갖는 페이로드로서 제2 타입의 프레임에 캡슐화함으로서 형성된 데이터 패킷을 물리층측 디바이스에로부터 네트워크층측 디바이스로 전송하는 - 상기 제1 타입의 프레임은 각각 시작 플래그, 어드레스 필드, 제어 필드, 정보 필드, FCS 필드, 및 종료 필드를 포함함 - 데이터 전송 방법에 있어서,

상기 물리층측 디바이스로부터 데이터 패킷을 수신하는 단계;

상기 오버헤드를 제거하고, 상기 제2 타입의 프레임의 페이로드로부터 상기 제1 타입의 프레임을 추출하는 제2 역프레임화 단계;

상기 제1 타입의 프레임으로부터 상기 정보 필드에 포함된 데이터 및 어드레스 필드를 추출하는 제1 역프레임화 단계;

적어도 제1 값 및 제2 값을 포함하는 미리 설정된 값의 세트와 상기 어드레스 필드(SAPI 필드)의 값을 비교하고, 상기 어드레스 필드 데이터의 값이 상기 제1 값과 정합되면, 추출된 데이터가 제1 타입인 것으로 결정하고, 상기 어드레스 필드의 값이 상기 제2 값과 정합하면, 추출된 데이터가 제2 타입인 것으로 결정하는 단계; 및

추출된 데이터 패킷과 결정 결과를 상기 네트워크층측 디바이스에 전송하는 단계

를 포함하는 것을 특징으로 하는 데이터 전송 방법.
제51항에 있어서,

X⁴³+ 1 디스크램블 처리를 실행하여 스크램블 처리되지 않은 비트를 만드는 역스크램블 처리 단계를 더 포함하는 것을 특징으로 하는 데이터 전송 방법.
제52항에 있어서,

상기 시작 플래그 및 종료 플래그는 "0x7E"인 것을 특징으로 하는 데이터 전송 방법.
제53항에 있어서,

상기 제1 역프레임화 단계는 프레임 사이를 채운 것을 제거하는 것을 특징으로 하는 데이터 전송 방법.
제54항에 있어서,

상기 제1 역프레임화 단계는 0x7D, 0x5E를 0x7E로 또한 0x7D, 0x5D를 0x7D로 복호화하기 위해 디스터핑 과정을 실행하는 것을 특징으로 하는 데이터 전송 방법.
제55항에 있어서,

수신된 FCS 필드는 발생기 다항식: 1 + x + x²+ x⁴+ x⁵+ x⁷+ x⁸+ x¹⁰+ x¹¹+ x¹²+ x¹⁶+ x²²+x²³+ x²⁶+ x³²에 의해, 상기 시작 플래그와 종료 플래그 사이에 모든 옥텟에 걸쳐 FCS 점검합을 계산함으로서 검증되는 것을 특징으로 하는 데이터 전송 방법.
제56항에 있어서,

이전 프레임의 종료 플래그는 상기 이전 프레임 다음에 이어지는 프레임의 시작 플래그인 것을 특징으로 하는 데이터 전송 방법.
제57항에 있어서,

상기 출력 데이터 패킷은 네트워크층으로 전송되기 이전에 비율 적응을 위해 버퍼 처리되는 것을 특징으로 하는 데이터 전송 방법.
제51항 내지 제58항 중 한 항에 있어서,

상기 물리층은 SDH/SONET, 간략화된 SDH/SONET, 의사-동기화 디지털 계층구조, 및 WDM 중 하나인 것을 특징으로 하는 데이터 전송 방법.
제51항 내지 제59항 중 한 항에 있어서,

상기 제1 타입의 프레임은 LAPS 프레임이고, 상기 제2 타입의 프레임은 SDH/SONET형 프레임이고, 또한 상기 그로부터 추출된 데이터 패킷은 Ipv4, Ipv6, IS-IS, PPP 패킷, 또는 MPEG 데이터 스트림인 것을 특징으로 하는 데이터 전송 방법.