| < draft-malis-sonet-ces-mpls-04.txt | draft-malis-sonet-ces-mpls-05.txt > | |||
|---|---|---|---|---|
| Network Working Group Andrew G. Malis | Network Working Group Andrew G. Malis | |||
| Internet Draft Ken Hsu | Internet Draft Ken Hsu | |||
| Expiration Date: October 2001 Vivace Networks, Inc. | Expiration Date: February 2002 Vivace Networks, Inc. | |||
| Jeremy Brayley | Jeremy Brayley | |||
| Steve Vogelsang | Steve Vogelsang | |||
| John Shirron | John Shirron | |||
| Laurel Networks, Inc. | Laurel Networks, Inc. | |||
| Luca Martini | Luca Martini | |||
| Level 3 Communications, LLC. | Level 3 Communications, LLC. | |||
| Tom Johnson | Tom Johnson | |||
| Marlene Drost | Marlene Drost | |||
| Ed Hallman | Ed Hallman | |||
| Litchfield Communications | Litchfield Communications, Inc. | |||
| April 2001 | July 2001 | |||
| SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation | SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation | |||
| draft-malis-sonet-ces-mpls-04.txt | draft-malis-sonet-ces-mpls-05.txt | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
| all provisions of section 10 of RFC 2026 [1]. | all provisions of section 10 of RFC 2026 [1]. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| 1. Abstract | 1. Abstract | |||
| This document describes a method for encapsulating SONET/SDH Path | This document describes a method for encapsulating SONET/SDH Path | |||
| signals for transport across an MPLS network. | signals for transport across packet-switched networks (PSNs). The PSNs | |||
| explicitly supported by this document include MPLS and IP. | ||||
| 2. Conventions used in this document | 2. Conventions used in this document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [2]. | document are to be interpreted as described in RFC 2119 [2]. | |||
| 3. Introduction | 3. Introduction | |||
| This document describes a method for encapsulating time division | This document describes a method for encapsulating time division | |||
| multiplexed (TDM) digital signals for transmission over a packet- | multiplexed (TDM) digital signals for transmission over packet- | |||
| oriented MPLS network. The transmission system for circuit-oriented | switched networks. | |||
| TDM signals is the Synchronous Optical Network (SONET) [3], [6] / | ||||
| Synchronous Digital Hierarchy (SDH) [4]. To support TDM traffic, | The transmission system for circuit-oriented TDM signals is the | |||
| which includes voice, data, and private leased line service, the | Synchronous Optical Network (SONET) [3], [6] / Synchronous Digital | |||
| MPLS network must emulate the circuit characteristics of SONET/SDH | Hierarchy (SDH) [4]. To support TDM traffic (which includes voice, | |||
| payloads. MPLS labels and a new circuit emulation header are used | data, and private leased line services) PSNs must emulate the | |||
| to encapsulate TDM signals and provide the Circuit Emulation Service | circuit characteristics of SONET/SDH payloads. MPLS labels and a | |||
| over MPLS (CEM). | new circuit emulation header are used to encapsulate TDM signals and | |||
| provide the Circuit Emulation Service over MPLS (CEM) function. The | ||||
| MPLS encapsulation may be further encapsulated in IP for carriage | ||||
| across IP PSNs [8]. | ||||
| This document also describes an optional extension to CEM called | This document also describes an optional extension to CEM called | |||
| Dynamic Bandwidth Allocation (DBA). This is a method for | Dynamic Bandwidth Allocation (DBA). This is a method for | |||
| dynamically reducing the bandwidth utilized by emulated SONET/SDH | dynamically reducing the bandwidth utilized by emulated SONET/SDH | |||
| circuits in the packet network. This bandwidth reduction is | circuits in the packet network. This bandwidth reduction is | |||
| accomplished by not sending the SONET/SDH payload through the packet | accomplished by not sending the SONET/SDH payload through the packet | |||
| network under certain conditions such as AIS-P or STS SPE | network under certain conditions such as AIS-P or STS SPE | |||
| Unequipped. | Unequipped. | |||
| This document is closely related to references [5], which describes | This document is closely related to references [5], which describes | |||
| the control protocol methods used to signal the usage of CEM, and | the control protocol methods used to signal the usage of CEM, [7], | |||
| [7], which describes a related method of encapsulating Layer 2 | which describes a related method of encapsulating Layer 2 frames | |||
| frames over MPLS and which shares the same signaling. | over MPLS and which shares the same signaling, and [11] which | |||
| describes a MIB for controlling and observing CEM services. | ||||
| 4. Scope | 4. Scope | |||
| This document describes how to provide CEM for the following digital | This document describes how to provide CEM for the following digital | |||
| signals: | signals: | |||
| 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 | 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 | |||
| 2. STS-Nc SPE (N = 3, 12, or 48)/SDH VC-4, VC-4-4c, VC-4-16c | 2. STS-Nc SPE (N = 3, 12, or 48)/SDH VC-4, VC-4-4c, VC-4-16c | |||
| 3. Unstructured SONET Emulation, where the entire SONET bit-stream | ||||
| (including the transport overhead) is packetized and transported | ||||
| across the PSN. | ||||
| For the remainder of this document, these constructs will be | For the remainder of this document, these constructs will be | |||
| referred to as SONET/SDH channels. | referred to as SONET/SDH channels. | |||
| Other SONET/SDH signals, such as virtual tributary (VT) structured | Other SONET/SDH signals, such as virtual tributary (VT) structured | |||
| sub-rate mapping, are not explicitly discussed in this document; | sub-rate mapping, are not explicitly discussed in this document; | |||
| however, it can be extended in the future to support VT and lower | however, it can be extended in the future to support VT and lower | |||
| speed non-SONET/SDH services. OC-192c SPE/VC-4-64c are also not | speed non-SONET/SDH services. OC-192c SPE/VC-4-64c are also not | |||
| included at this point, since most MPLS networks use OC-192c or | included at this point, since most PSNs use OC-192c or slower | |||
| slower trunks, and thus would not have sufficient capacity. As | trunks, and thus would not have sufficient capacity. As trunk | |||
| trunk capacities increase in the future, the scope of this document | capacities increase in the future, the scope of this document can be | |||
| can be accordingly extended. | accordingly extended. | |||
| 5. CEM Encapsulation Format | 5. CEM Encapsulation Format | |||
| In order to transport SONET/SDH SPEs through a packet-oriented | In order to transport SONET/SDH SPEs through a packet-oriented | |||
| network, the SPE is broken into fragments. A 32-bit CEM Header is | network, the SPE is broken into fragments. A 32-bit CEM Header is | |||
| pre-pended to each fragment. The Basic CEM packet appears in Figure | pre-pended to each fragment. The Basic CEM packet appears in Figure | |||
| 1. | 1. | |||
| +-----------------------------------+ | +-----------------------------------+ | |||
| | CEM Header | | | CEM Header | | |||
| skipping to change at page 3, line 32 ¶ | skipping to change at page 3, line 41 ¶ | |||
| | | | | | | |||
| +-----------------------------------+ | +-----------------------------------+ | |||
| Figure 1. Basic CEM Packet | Figure 1. Basic CEM Packet | |||
| The 32-bit CEM header has the following format: | The 32-bit CEM header has the following format: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |D|Resvd| Sequence Num | Structure Pointer |N|P| ECC-6 | | |D|R|Rvd| Sequence Num | Structure Pointer |N|P| ECC-6 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 2. CEM Header Format | Figure 2. CEM Header Format | |||
| The above fields are defined as follows: | The above fields are defined as follows: | |||
| D bit: Signals DBA Mode. MUST be set to zero for Normal Operation. | D bit: Signals DBA Mode. MUST be set to zero for Normal Operation. | |||
| MUST be set to one if CEM is currently in DBA mode. DBA is an | MUST be set to one if CEM is currently in DBA mode. DBA is an | |||
| optional mode during which trivial SPEs are not transmitted into the | optional mode during which trivial SPEs are not transmitted into the | |||
| packet network. See Table 1 and sections 7 and 8 for further | packet network. See Table 1 and sections 7 and 8 for further | |||
| details. | details. Note: for unstructured CEM, the D-bit MUST be set to zero. | |||
| Reserved: These bits are reserved for future use, and MUST be set to | R bit: CEM-RDI. This bit is set to one to signal to the remote CEM | |||
| function that a loss of packet synchronization has occurred. | ||||
| Rvd: These bits are reserved for future use, and MUST be set to | ||||
| zero. | zero. | |||
| Sequence Number: This is a packet sequence number, which MUST | Sequence Number: This is a packet sequence number, which MUST | |||
| continuously cycle from 0 to 1023. It SHOULD begin at zero when a | continuously cycle from 0 to 1023. It SHOULD begin at zero when a | |||
| CEM LSP is created. | CEM LSP is created. | |||
| Structure Pointer: The Structure Pointer MUST contain the offset of | Structure Pointer: The Structure Pointer MUST contain the offset of | |||
| the J1 byte within the CEM payload. The value is from 0 to 1,022, | the J1 byte within the CEM payload. The value is from 0 to 1,022, | |||
| where 0 means the first byte after the CEM header. The Structure | where 0 means the first byte after the CEM header. The Structure | |||
| Pointer MUST be set to 0x3FF (1,023) if a packet does not carry the | Pointer MUST be set to 0x3FF (1,023) if a packet does not carry the | |||
| J1 byte. See [3], [4] and [6] for more information on the J1 byte | J1 byte. See [3], [4] and [6] for more information on the J1 byte | |||
| and the SONET/SDH payload pointer. | and the SONET/SDH payload pointer. Note: for unstructured CEM, the | |||
| Structure Pointer field MUST be set to 0x3FF. | ||||
| The N and P bits: Indicate negative and positive pointer adjustment | The N and P bits: Indicate negative and positive pointer adjustment | |||
| events. They are also used to relay SONET/SDH maintenance signals | events. They are also used to relay SONET/SDH maintenance signals | |||
| such as AIS-P. See Table 1 and sections 7 and 8 for more details. | such as AIS-P. See Table 1 and sections 7 and 8 for more details. | |||
| Note: for unstructured CEM, the N and P bits MUST both be set to 0. | ||||
| +---+---+---+----------------------------------------------+ | +---+---+---+----------------------------------------------+ | |||
| | D | N | P | Interpretation | | | D | N | P | Interpretation | | |||
| +---+---+---+----------------------------------------------+ | +---+---+---+----------------------------------------------+ | |||
| | 0 | 0 | 0 | Normal Mode û No Ptr Adjustment | | | 0 | 0 | 0 | Normal Mode “ No Ptr Adjustment | | |||
| | 0 | 0 | 1 | Normal Mode û Positive Ptr Adjustment | | | 0 | 0 | 1 | Normal Mode “ Positive Ptr Adjustment | | |||
| | 0 | 1 | 0 | Normal Mode û Negative Ptr Adjustment | | | 0 | 1 | 0 | Normal Mode “ Negative Ptr Adjustment | | |||
| | 0 | 1 | 1 | Normal Mode û AIS-P | | | 0 | 1 | 1 | Normal Mode “ AIS-P | | |||
| | | | | | | | | | | | | |||
| | 1 | 0 | 0 | DBA Mode û STS SPE Unequipped | | | 1 | 0 | 0 | DBA Mode “ STS SPE Unequipped | | |||
| | 1 | 0 | 1 | DBA Mode û STS SPE Unequipped Pos Ptr Adj | | | 1 | 0 | 1 | DBA Mode “ STS SPE Unequipped Pos Ptr Adj | | |||
| | 1 | 1 | 0 | DBA Mode û STS SPE Unequipped Neg Ptr Adj | | | 1 | 1 | 0 | DBA Mode “ STS SPE Unequipped Neg Ptr Adj | | |||
| | 1 | 1 | 1 | DBA Mode û AIS-P | | | 1 | 1 | 1 | DBA Mode “ AIS-P | | |||
| +---+---+---+----------------------------------------------+ | +---+---+---+----------------------------------------------+ | |||
| Table 1. Interpretation of D, N, and P bits | Table 1. Interpretation of D, N, and P bits | |||
| ECC-6: An Error Correction Code to protect the CEM header. This | ECC-6: An Error Correction Code to protect the CEM header. This | |||
| offers the ability to correct single bit errors and detect up to two | offers the ability to correct single bit errors and detect up to two | |||
| bit errors. The ECC algorithm is described in Appendix B. | bit errors. The ECC algorithm is described in Appendix B. The ECC- | |||
| 6 can be optionally disabled at provisioning time. If the ECC-6 is | ||||
| not utilized it MUST be set to zero. | ||||
| Note: CEM packets are fixed in length for all of the packets of a | Note: Normal CEM packets are fixed in length for all of the packets | |||
| particular emulated TDM stream. This length is signaled using the | of a particular emulated TDM stream. This length is signaled using | |||
| CEM Payload Bytes parameter defined in [5], or is statically | the CEM Payload Bytes parameter defined in [5], or is statically | |||
| provisioned for each TDM stream. Therefore, the length of each CEM | provisioned for each TDM stream. Therefore, the length of each CEM | |||
| packet does not need to be carried in the CEM header. | packet does not need to be carried in the CEM header. | |||
| 5.1 Transport Encapsulation | 5.1 Transport Encapsulation | |||
| In principle, CEM packets can be transported over any packet- | In principle, CEM packets can be transported over any packet- | |||
| oriented network. The following sections describe specifically how | oriented network. The following sections describe specifically how | |||
| CEM packets MUST be encapsulated for transport over MPLS or IP | CEM packets MUST be encapsulated for transport over MPLS or IP | |||
| networks. | networks. | |||
| 5.1.1 MPLS Transport | 5.1.1 MPLS Transport | |||
| To transport a CEM packet over an MPLS network, an MPLS label-stack | To transport a CEM packet over an MPLS network, an MPLS label-stack | |||
| MUST be pushed on top of the CEM packet. | MUST be pushed on top of the CEM packet. | |||
| The last two labels prior to the CEM header are referred to as the | The last two labels prior to the CEM header are referred to as the | |||
| Tunnel and VC labels. | Tunnel and Virtual Circuit (VC) labels. | |||
| The VC label is required, and is the last label prior to the CEM | The VC label is required, and is the last label prior to the CEM | |||
| Header. The VC label MUST be used to identify the CEM connection | Header. The VC label MUST be used to identify the CEM connection | |||
| within the MPLS tunnel. | within the MPLS tunnel. | |||
| The optional tunnel label is immediately above the VC label on the | The optional tunnel label is immediately above the VC label on the | |||
| label stack. If present, the tunnel label MUST be used to identify | label stack. If present, the tunnel label MUST be used to identify | |||
| the MPLS LSP used to tunnel the TDM packets through the MPLS network | the MPLS LSP used to tunnel the TDM packets through the MPLS network | |||
| (the tunnel LSP). | (the tunnel LSP). | |||
| skipping to change at page 7, line 11 ¶ | skipping to change at page 7, line 11 ¶ | |||
| +-----------------------------------+ | +-----------------------------------+ | |||
| Figure 4. MPLS Transport Encapsulation | Figure 4. MPLS Transport Encapsulation | |||
| 6. CEM Operation | 6. CEM Operation | |||
| The following sections describe CEM operation. | The following sections describe CEM operation. | |||
| 6.1 Introduction and Terminology | 6.1 Introduction and Terminology | |||
| CEM MUST support a normal mode of operation and MAY support an | There are two types of CEM: structured and unstructured. | |||
| optional extension called Dynamic Bandwidth Allocation (DBA). | ||||
| During normal operation, SONET/SDH payloads are fragmented, pre- | Unstructured CEM packetizes the entire SONET/SDH bit-stream | |||
| pended with the CEM Header and the MPLS label-stack, and then | (including transport overhead). | |||
| transmitted into the packet network. During DBA mode, only the CEM | ||||
| header and MPLS label stack are transmitted. This is done to | Structured CEM terminates the transport overhead and packetizes | |||
| conserve bandwidth when meaningful user data is not present in the | individual channels (STS-1/Nc) within the SONET/SDH frame. Because | |||
| SPE, such as during AIS-P or STS SPE Unequipped. | structured CEM terminates the transport overhead, structured CEM | |||
| implementations SHOULD meet the generic requirements for SONET/SDH | ||||
| Line Terminating Equipment as defined in [3], [4], and [6]. | ||||
| Implementations MUST support structured CEM and MAY support | ||||
| unstructured CEM. | ||||
| Structured CEM MUST support a normal mode of operation and MAY | ||||
| support an optional extension called Dynamic Bandwidth Allocation | ||||
| (DBA). During normal operation, SONET/SDH payloads are fragmented, | ||||
| pre-pended with the CEM Header, the VC label, and the PSN header, | ||||
| and then transmitted into the packet network. During DBA mode, only | ||||
| the CEM header, the VC label, and PSN header are transmitted. This | ||||
| is done to conserve bandwidth when meaningful user data is not | ||||
| present in the SPE, such as during AIS-P or STS SPE Unequipped. | ||||
| 6.1.1 CEM Packetizer and De-Packetizer | 6.1.1 CEM Packetizer and De-Packetizer | |||
| As with all adaptation functions, CEM has two distinct components: | As with all adaptation functions, CEM has two distinct components: | |||
| adapting TDM SONET/SDH into a CEM packet stream, and converting the | adapting TDM SONET/SDH into a CEM packet stream, and converting the | |||
| CEM packet stream back into a TDM SONET/SDH. The first function | CEM packet stream back into a TDM SONET/SDH. The first function | |||
| will be referred to as CEM Packetizer and the second as CEM De- | will be referred to as CEM Packetizer and the second as CEM De- | |||
| Packetizer. This terminology is illustrated in figure 5. | Packetizer. This terminology is illustrated in figure 5. | |||
| +------------+ +---------------+ | +------------+ +---------------+ | |||
| | | | | | | | | | | |||
| SONET --> | CEM | --> MPLS --> | CEM | --> SONET | SONET --> | CEM | --> PSN --> | CEM | --> SONET | |||
| SDH | Packetizer | | De-Packetizer | SDH | SDH | Packetizer | | De-Packetizer | SDH | |||
| | | | | | | | | | | |||
| +------------+ +---------------+ | +------------+ +---------------+ | |||
| Figure 5. CEM Terminology | Figure 5. CEM Terminology | |||
| Note: the CEM receive function requires a buffering mechanism to | Note: the CEM de-packetizer requires a buffering mechanism to | |||
| account for delay variation in the CEM packet stream. This | account for delay variation in the CEM packet stream. This | |||
| buffering mechanism will be generically referred to as the CEM | buffering mechanism will be generically referred to as the CEM | |||
| jitter buffer. | jitter buffer. | |||
| 6.1.2 CEM DBA | 6.1.2 CEM DBA | |||
| CEM DBA is an optional mode of operation that only transmits the CEM | DBA is an optional mode of operation for structured CEM that only | |||
| Header and MPLS Label Stack into the packet network under certain | transmits the CEM Header, the VC label, and PSN Header into the | |||
| circumstances such as AIS-P or STS Unequipped. | packet network under certain circumstances such as AIS-P or STS | |||
| Unequipped. | ||||
| If DBA is supported by a CEM implementation, the user SHOULD be able | If DBA is supported by a CEM implementation, the user SHOULD be able | |||
| to configure if DBA will be triggered by AIS-P, STS Unequipped, | to configure if DBA will be triggered by AIS-P, STS Unequipped, | |||
| both, or neither on a per channel basis. | both, or neither on a per channel basis. | |||
| If DBA is supported, the determination of AIS-P and STS Unequipped | If DBA is supported, the determination of AIS-P and STS Unequipped | |||
| MUST be based on the state of SONET/SDH Section, Line, and Path | MUST be based on the state of SONET/SDH Section, Line, and Path | |||
| Overhead bytes. DBA based on pattern detection within the SPE (i.e. | Overhead bytes. DBA based on pattern detection within the SPE (i.e. | |||
| all zeros, 7Es, or ATM idle cells) is for further study. | all zeros, 7Es, or ATM idle cells) is for further study. | |||
| During AIS-P, there is no valid payload pointer, so pointer | During AIS-P, there is no valid payload pointer, so pointer | |||
| adjustments cannot occur. During STS Unequipped, the SONET/SDH | adjustments cannot occur. During STS Unequipped, the SONET/SDH | |||
| payload pointer is valid, and therefore pointer adjustments MUST be | payload pointer is valid, and therefore pointer adjustments MUST be | |||
| supported even during DBA. See Table 1 for details. | supported even during DBA. See Table 1 for details. | |||
| 6.2 Description of Normal CEM Operation | 6.2 Description of Normal CEM Operation | |||
| During normal operation, the CEM packetizer will receive a fixed | During normal operation, the CEM packetizer will receive a fixed | |||
| rate byte stream from a SONET/SDH interface. When a packets worth | rate byte stream from a SONET/SDH interface. When a packets worth | |||
| of data has been received from a SONET/SDH channel, the CEM Header | of data has been received from a SONET/SDH channel, the CEM Header, | |||
| and MPLS label stack are pre-pended to the SPE fragment and the | the VC Label, and PSN Header are pre-pended to the SPE fragment and | |||
| resulting CEM packet is transmitted into the MPLS network. Because | the resulting CEM packet is transmitted into the packet network. | |||
| all CEM packets associated with a specific SONET/SDH channel will | Because all normal CEM packets associated with a specific SONET/SDH | |||
| have the same length, the transmission of CEM packets for that | channel will have the same length, the transmission of CEM packets | |||
| channel SHOULD occur at regular intervals. | for that channel SHOULD occur at regular intervals. | |||
| At the far end of the packet network, the CEM de-packetizer will | At the far end of the packet network, the CEM de-packetizer will | |||
| receive packets into a jitter buffer and then play out the received | receive packets into a jitter buffer and then play out the received | |||
| byte stream at a fixed rate onto the corresponding SONET/SDH | byte stream at a fixed rate onto the corresponding SONET/SDH | |||
| channel. The jitter buffer SHOULD be adjustable in length to | channel. The jitter buffer SHOULD be adjustable in length to | |||
| account for varying network delay behavior. The receive packet rate | account for varying network delay behavior. The receive packet rate | |||
| from the packet network should be exactly balanced by the | from the packet network should be exactly balanced by the | |||
| transmission rate onto the SONET/SDH channel, on average. The time | transmission rate onto the SONET/SDH channel, on average. The time | |||
| over which this average is taken corresponds to the depth of the | over which this average is taken corresponds to the depth of the | |||
| jitter buffer for a specific CEM channel. | jitter buffer for a specific CEM channel. | |||
| The CEM sequence numbers provide a mechanism to detect lost and/or | ||||
| mis-ordered packets. The CEM de-packetizer MUST detect lost or mis- | ||||
| ordered packets. The CEM de-packetizer MUST play out a programmable | ||||
| byte pattern in place of any dropped packets. The CEM de-packetizer | ||||
| MAY re-order packets received out of order. If the CEM de- | ||||
| packetizer does not support re-ordering, it MUST drop mis-ordered | ||||
| packets. | ||||
| 6.3 Description of CEM Operation during DBA | 6.3 Description of CEM Operation during DBA | |||
| (Note: DBA is only applicable to structured CEM.) | ||||
| There are several issues that should be addressed by a workable CEM | There are several issues that should be addressed by a workable CEM | |||
| DBA mechanism. First, when DBA is invoked, there should be a | DBA mechanism. First, when DBA is invoked, there should be a | |||
| substantial savings in bandwidth utilization in the packet network. | substantial savings in bandwidth utilization in the packet network. | |||
| The second issue is that the transition in and out of DBA should be | The second issue is that the transition in and out of DBA should be | |||
| tightly coordinated between the local CEM packetizer and CEM de- | tightly coordinated between the local CEM packetizer and CEM de- | |||
| packetizer at the far side of the packet network. A third is that | packetizer at the far side of the packet network. A third is that | |||
| the transition in and out of DBA should be accomplished with minimal | the transition in and out of DBA should be accomplished with minimal | |||
| disruption to the adapted data stream. | disruption to the adapted data stream. | |||
| Another goal is that the reduction of CEM traffic due to DBA should | Another goal is that the reduction of CEM traffic due to DBA should | |||
| skipping to change at page 8, line 54 ¶ | skipping to change at page 9, line 25 ¶ | |||
| Finally, the implementation of DBA should require minimal | Finally, the implementation of DBA should require minimal | |||
| modifications beyond what is necessary for the nominal CEM case. | modifications beyond what is necessary for the nominal CEM case. | |||
| The mechanism described below is a reasonable balance of these | The mechanism described below is a reasonable balance of these | |||
| goals. | goals. | |||
| During DBA, packets MUST be emitted at exactly the same rate as they | During DBA, packets MUST be emitted at exactly the same rate as they | |||
| would be during normal operation. This SHOULD be accomplished by | would be during normal operation. This SHOULD be accomplished by | |||
| transmitting each DBA packet after a complete packet of data has | transmitting each DBA packet after a complete packet of data has | |||
| been received from the SONET/SDH channel. The only change from | been received from the SONET/SDH channel. The only change from | |||
| normal operation is that the CEM packets during DBA MUST only carry | normal operation is that the CEM packets during DBA MUST only carry | |||
| the CEM header and the MPLS label stack. The D-bit MUST be set to | the CEM header, the VC Label, and the PSN Header. | |||
| one, to indicate that DBA is active. | ||||
| Because some links have a minimum supported packet size, the CEM | ||||
| packetizer MAY append a configurable number of bytes immediately | ||||
| after the CEM-header to pad out the CEM packet to reach the mimumum | ||||
| supported packet size. The value of the padding bytes is | ||||
| implementation specific. The D-bit MUST be set to one, to indicate | ||||
| that DBA is active. | ||||
| The CEM de-packetizer MUST assume that each packet received with the | The CEM de-packetizer MUST assume that each packet received with the | |||
| D-bit set represents a normal-sized packet containing an AIS-P or | D-bit set represents a normal-sized packet containing an AIS-P or | |||
| SPE Unequipped payload as noted by N and P. See Table 1. | SPE Unequipped payload as noted by N and P. See Table 1. The CEM | |||
| de-packetizer MUST accept DBA packets with or without padding. | ||||
| This allows the CEM packetization and de-packetization logic during | This allows the CEM packetization and de-packetization logic during | |||
| DBA to be virtually identical to the nominal case. It insures that | DBA to be similar to the nominal case. It insures that the correct | |||
| the correct SONET/SDH indication is reliably transmitted between CEM | SONET/SDH indication is reliably transmitted between CEM adaptation | |||
| adaptation points. It minimizes the risk of under or over running | points. It minimizes the risk of under or over running the jitter | |||
| the jitter buffer during the transition in and out of DBA. And, it | buffer during the transition in and out of DBA. And, it guarantees | |||
| guarantees that faults in the packet network are recognized as | that faults in the packet network are recognized as distinctly | |||
| distinctly different from line conditioning on the SONET/SDH | different from line conditioning on the SONET/SDH interfaces. | |||
| interfaces. | ||||
| 6.4 Packet Synchronization | ||||
| A key component in declaring the state of a CEM service is whether | ||||
| or not the CEM de-packetizer is in or out of packet synchronization. | ||||
| The following paragraphs describe how that determination is made. | ||||
| 6.4.1 Acquisition of Packet Synchronization | ||||
| At startup, a CEM de-packetizer will be out of packet | ||||
| synchronization by default. To declare packet synchronization at | ||||
| startup or after a loss of packet synchronization, the CEM de- | ||||
| packetizer must receive a configurable number of CEM packets with | ||||
| sequential sequence numbers. | ||||
| 6.4.2 Loss of Packet Synchronization | ||||
| Once a CEM de-packetizer is in packet sync, it may encounter a set | ||||
| of events that will cause it to lose packet synchronization. | ||||
| As discussed in section 6.2, a CEM de-packetizer MAY or MAY NOT | ||||
| support re-ordering of mis-ordered packets. | ||||
| If a CEM de-packetizer supports re-ordering, then the determination | ||||
| that packet synchronization has been lost cannot be made at the time | ||||
| the packets are received from the PSN. Instead, the determination | ||||
| MUST be made as the packets are being played out onto the SONET/SDH | ||||
| interface. This is because it is only at play-out time that the | ||||
| determination can be made as to whether the entire emulated | ||||
| SONET/SDH stream was received from the PSN. | ||||
| If a CEM de-packetizer does not support re-ordering, a number of | ||||
| approaches may be used to minimize the impact of mis-ordered or lost | ||||
| packets on the final re-assembled SONET/SDH stream. For example, | ||||
| AAL1 [9] uses a simple state-machine to re-order packets in a sub- | ||||
| set of possible cases. The algorithm for these state-machines is | ||||
| outside of the scope of CEM. However, the final determination as to | ||||
| whether or not to declare loss of packet synchronization MUST be | ||||
| based on the same criteria as for implementations that do support | ||||
| re-ordering. | ||||
| Whether or not a CEM implementation supports re-ordering, the | ||||
| declaration of loss of packet synchronization MUST be based on the | ||||
| following criteria. | ||||
| As packets are played out towards the SONET/SDH interface, the CEM | ||||
| de-packetizer will encounter Ÿempty÷ packets in the place of packets | ||||
| that were dropped by the PSN, or effectively dropped due to | ||||
| limitations of the CEM implementation. If the CEM de-packetizer | ||||
| encounters more than a configurable number of sequential dropped | ||||
| packets, the CEM de-packetizer MUST declare loss of packet | ||||
| synchronization. | ||||
| 7. SONET/SDH Maintenance Signals | 7. SONET/SDH Maintenance Signals | |||
| There are several issues that must be considered in the mapping of | There are several issues that must be considered in the mapping of | |||
| maintenance signals between SONET/SDH and MPLS. A description of | maintenance signals between SONET/SDH and a PSN. A description of | |||
| how these signals and conditions are mapped between the two domains | how these signals and conditions are mapped between the two domains | |||
| is described below. | is described below. | |||
| For clarity, the mappings are split into two groups: SONET/SDH to | For clarity, the mappings are split into two groups: SONET/SDH to | |||
| MPLS, and MPLS to SONET/SDH. | PSN, and PSN to SONET/SDH. | |||
| 7.1 SONET/SDH to MPLS | 7.1 SONET/SDH to PSN | |||
| The following sections describe how SONET/SDH Maintenance Signals | The following sections describe how SONET/SDH Maintenance Signals | |||
| and Alarm conditions are mapped into MPLS. | and Alarm conditions are mapped into a Packet Switched Network. | |||
| 7.1.1 AIS-P Indication | 7.1.1 AIS-P Indication | |||
| In a SONET/SDH network, circuit outages are signaled using | In a SONET/SDH network, SONET/SDH Path outages are signaled using | |||
| maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P | maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P | |||
| indicates that the SONET/SDH Path is not currently transmitting | indicates that the SONET/SDH Path is not currently transmitting | |||
| valid end-user data, and the SPE contains all ones. | valid end-user data, and the SPE contains all ones. | |||
| It should be noted that nearly every type of service-effecting | It should be noted that for structured CEM nearly every type of | |||
| section or line defect will result in an AIS-P condition. | service-effecting section or line defect will result in an AIS-P | |||
| condition. | ||||
| The SONET/SDH hierarchy is illustrated below. | The SONET/SDH hierarchy is illustrated below. | |||
| +----------+ | +----------+ | |||
| | PATH | | | PATH | | |||
| +----------+ | +----------+ | |||
| ^ | ^ | |||
| | | | | |||
| AIS-P | AIS-P | |||
| | | | | |||
| | | | | |||
| skipping to change at page 10, line 31 ¶ | skipping to change at page 12, line 44 ¶ | |||
| +----------+ | +----------+ | |||
| | SECTION | | | SECTION | | |||
| +----------+ | +----------+ | |||
| ^ ^ | ^ ^ | |||
| | | | | | | |||
| | | | | | | |||
| LOS LOF | LOS LOF | |||
| Figure 6. SONET/SDH Fault Hierarchy. | Figure 6. SONET/SDH Fault Hierarchy. | |||
| Should the Section Layer detect a Loss of Section (LOS) or Loss of | Should the Section Layer detect a Loss of Signal (LOS) or Loss of | |||
| Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the | Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the | |||
| Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to | Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to | |||
| the Path Layer. | the Path Layer. | |||
| In normal mode during AIS-P, CEM packets are generated as usual. | In normal mode during AIS-P, structured CEM packets are generated as | |||
| The N and P bits MUST be set to 11 binary to signal AIS-P explicitly | usual. The N and P bits MUST be set to 11 binary to signal AIS-P | |||
| through the packet network. The D-bit MUST be set to zero to | explicitly through the packet network. The D-bit MUST be set to | |||
| indicate that the SPE is being carried through the packet network. | zero to indicate that the SPE is being carried through the packet | |||
| Normal CEM packets with the SPE fragment, CEM Header, and MPLS label | network. Normal CEM packets with the SPE fragment, CEM Header, the | |||
| stack MUST be transmitted into the packet network. | VC Label, and PSN Header MUST be transmitted into the packet | |||
| network. | ||||
| However, to conserve network bandwidth during AIS-P, DBA MAY be | However, to conserve network bandwidth during AIS-P, DBA MAY be | |||
| employed. If DBA has been enabled for AIS-P and AIS-P is currently | employed. If DBA has been enabled for AIS-P and AIS-P is currently | |||
| occurring, the N and P bits MUST be set to 11 binary to signal AIS, | occurring, the N and P bits MUST be set to 11 binary to signal AIS, | |||
| and the D-bit MUST be set to one to indicate that the SPE is not | and the D-bit MUST be set to one to indicate that the SPE is not | |||
| being carried through the packet network. Only the CEM header and | being carried through the packet network. Only the CEM header, the | |||
| the MPLS label stack MUST be transmitted into the packet network. | VC Label, and the PSN Header MUST be transmitted into the packet | |||
| network. | ||||
| Also note that this differs from the outage mechanism in [5], which | Also note that this differs from the outage mechanism in [5], which | |||
| withdraws labels as a result of an endpoint outage. TDM circuit | withdraws the VC label as a result of an endpoint outage. TDM | |||
| emulation requires the ability to distinguish between the de- | circuit emulation requires the ability to distinguish between the | |||
| provisioning of a circuit, which would cause the labels to be | de-provisioning of a circuit (which causes the VC label to be | |||
| withdrawn, and temporary outages, which are signaled using AIS-P. | withdrawn), and temporary outages (which are signaled using AIS-P). | |||
| 7.1.2 STS SPE Unequipped Indication | 7.1.2 STS SPE Unequipped Indication | |||
| The STS SPE Unequipped Indication is a slightly different case than | The STS SPE Unequipped Indication is a slightly different case than | |||
| AIS-P. When byte C2 of the Path Overhead (STS path signal label) is | AIS-P. When byte C2 of the Path Overhead (STS path signal label) is | |||
| 00h and Byte B3 (STS Path BIP-8) is valid, it indicates that the SPE | 00h and Byte B3 (STS Path BIP-8) is valid, it indicates that the SPE | |||
| is unequipped. Note: this is typically signaled by setting the | is unequipped. Note: this is typically signaled by setting the | |||
| entire SPE to zeros. | entire SPE to zeros. | |||
| For normal operation during SPE Unequipped, the N and P bits MUST be | For normal structured CEM operation during SPE Unequipped, the N and | |||
| interpreted as usual. The SPE MUST be transmitted into the packet | P bits MUST be interpreted as usual. The SPE MUST be transmitted | |||
| network along with the CEM Header and MPLS label stack, and the D- | into the packet network along with the CEM Header, the VC Label, and | |||
| Bit MUST be set to zero. | PSN Header, and the D-Bit MUST be set to zero. | |||
| If DBA has been enabled for STS SPE Unequipped and the Unequipped is | If DBA has been enabled for STS SPE Unequipped and the Unequipped | |||
| occurring on the SONET/SDH channel, the D-bit MUST be set to one to | condition is occurring on the SONET/SDH channel, the D-bit MUST be | |||
| indicate DBA is active. Only the CEM Header and MPLS Label Stack | set to one to indicate DBA is active. Only the CEM Header, the VC | |||
| must be transmitted into the packet network. The N and P bits MUST | Label, and PSN Header MUST be transmitted into the packet network. | |||
| be used to signal pointer adjustments as normal. See Table 1 and | The N and P bits MUST be used to signal pointer adjustments as | |||
| section 8 for details. | normal. See Table 1 and section 8 for details. | |||
| 7.1.3 RDI-P Indication | 7.1.3 CEM-RDI | |||
| The CEM function MUST send RDI-P towards the packet network under a | The CEM function MUST send CEM-RDI towards the packet network during | |||
| variety of network errors such as loss of packet synchronization. | loss of packet synchronization. This MUST be accomplished by | |||
| This MUST be accomplished by modifying the SONET/SDH Path Overhead | setting the R bit to one in the CEM header. This applies for both | |||
| within the CEM packets. Specifically the G1 byte must be updated to | structured and unstructured CEM. | |||
| signal RDI-P and the B3 (Path BIP-8) must be re-computed. See [3], | ||||
| [4], and [6] for details. | ||||
| 7.2 MPLS to SONET/SDH | 7.2 PSN to SONET/SDH | |||
| The following sections discuss how the various conditions on the | The following sections discuss how the various conditions on the | |||
| packet network are converted into SONET/SDH indications. | packet network are converted into SONET/SDH indications. | |||
| 7.2.1 AIS-P Indication | 7.2.1 AIS-P Indication | |||
| There are several conditions in the packet network that will cause | There are several conditions in the packet network that will cause | |||
| the CEM de-packetization function to send an AIS-P indication onto a | the structured CEM de-packetization function to send an AIS-P | |||
| SONET/SDH channel. | indication onto a SONET/SDH channel. | |||
| The first of these is the receipt of CEM packets with the N and P | The first of these is the receipt of structured CEM packets with the | |||
| bits set to one, and the D-bit set to zero. This is an explicit | N and P bits set to one, and the D-bit set to zero. This is an | |||
| indication of AIS-P being received at the far-end of the packet | explicit indication of AIS-P being received at the far-end of the | |||
| network, with DBA disabled for AIS-P. The CEM de-packetizer MUST | packet network, with DBA disabled for AIS-P. The CEM de-packetizer | |||
| play out the received SPE fragment (which will incidentally be | MUST play out the received SPE fragment (which will incidentally be | |||
| carrying all ones), and MUST configure the SONET/SDH Overhead to | carrying all ones), and MUST configure the SONET/SDH Overhead to | |||
| signal AIS-P as defined in [3], [4], and [6]. | signal AIS-P as defined in [3], [4], and [6]. | |||
| The second case is the receipt of CEM packets with the N and P bits | The second case is the receipt of structured CEM packets with the N | |||
| set to one, and the D-bit set to one. This is an explicit | and P bits set to one, and the D-bit set to one. This is an | |||
| indication of AIS-P being received at the far-end of the packet | explicit indication of AIS-P being received at the far-end of the | |||
| network, with DBA enabled for AIS-P. The CEM de-packetizer MUST | packet network, with DBA enabled for AIS-P. The CEM de-packetizer | |||
| play out one packetÆs worth of all ones for each packet received, | MUST play out one packetËs worth of all ones for each packet | |||
| and MUST configure the SONET/SDH Overhead to signal AIS-P as defined | received, and MUST configure the SONET/SDH Overhead to signal AIS-P | |||
| in [3], [4], and [6]. | as defined in [3], [4], and [6]. | |||
| Additional conditions that SHOULD trigger the transmission of AIS-P | A third case that will cause a structured CEM de-packetization | |||
| onto a SONET/SDH channel include loss of packet synchronization and | function to send an AIS-P indication onto a SONET/SDH channel is | |||
| jitter buffer under-run. The definition of these conditions are | loss of packet synchronization. | |||
| under investigation and will be clarified in a subsequent revision | ||||
| of this draft. | ||||
| 7.2.2 STS SPE Unequipped Indication | 7.2.2 STS SPE Unequipped Indication | |||
| There are two conditions in the packet network that will cause the | There are three conditions in the packet network that will cause the | |||
| CEM function to transmit STS SPE Unequipped indications onto the | CEM function to transmit STS SPE Unequipped indications onto the | |||
| SONET/SDH channel. | SONET/SDH channel. | |||
| The first, which is transparent to CEM, is the receipt of regular | The first, which is transparent to CEM, is the receipt of regular | |||
| CEM packets that happen to be carrying an SPE that contains the | CEM packets that happen to be carrying an SPE that contains the | |||
| appropriate Path overhead to signal STS SPE unequipped. This case | appropriate Path overhead to signal STS SPE unequipped. This case | |||
| does not require any special processing on the part of the CEM de- | does not require any special processing on the part of the CEM de- | |||
| packetizer. | packetizer. | |||
| The second case is the receipt of CEM packets that have the D-bit | The second case is the receipt of structured CEM packets that have | |||
| set to one to indicate DBA active and the N and P bits set to 00 | the D-bit set to one to indicate DBA active and the N and P bits set | |||
| binary, 01 binary, or 10 binary to indicate SPE Unequipped with or | to 00 binary, 01 binary, or 10 binary to indicate SPE Unequipped | |||
| without pointer adjustments. The CEM de-packetizer MUST use this | with or without pointer adjustments. The CEM de-packetizer MUST use | |||
| information to transmit a packet of all zeros onto the SONET/SDH | this information to transmit a packet of all zeros onto the | |||
| interface, and adjust the payload pointer as necessary. | SONET/SDH interface, and adjust the payload pointer as necessary. | |||
| 7.2.3 RDI-P Indication | ||||
| The CEM function MUST send an RDI-P towards a SONET/SDH channel | The third case when a structured CEM de-packetizer MUST send an STS | |||
| under the conditions defined for SONET/SDH Line Terminating | SPE Unequipped Indication towards the SONET/SDH interface is when | |||
| equipment in [3], [4], and [6]. | the VC-label has been withdrawn due to de-provisioning of the | |||
| circuit. | ||||
| 8. Clocking Modes | 8. Clocking Modes | |||
| It is necessary to be able to regenerate the input service clock at | It is necessary to be able to regenerate the input service clock at | |||
| the output interface. Two clocking modes are supported: synchronous | the output interface. Two clocking modes are supported: synchronous | |||
| and asynchronous. | and asynchronous. Selection of the clocking mode is made as part of | |||
| service provisioning. Both ends of the emulated circuit must be | ||||
| configured with the same clocking mode. | ||||
| 8.1 Synchronous | 8.1 Synchronous | |||
| When synchronous SONET/SDH timing is available at both ends of the | When synchronous SONET/SDH timing is available at both ends of the | |||
| circuit, the N and P bits are used to signal negative or positive | circuit, the issue of clock recovery becomes much simpler. | |||
| pointer justification events. | ||||
| 8.1.1 Synchronous Unstructured CEM | ||||
| For unstructured CEM, the external clock is used to clock each bit | ||||
| onto the optical carrier. | ||||
| 8.1.2 Synchronous Structured CEM | ||||
| For structured CEM, the external clock is used to clock the | ||||
| SONET/SDH carrier. The N and P bits are used to signal negative or | ||||
| positive pointer justification events between structured CEM end- | ||||
| points. | ||||
| If there is a frequency offset between the frame rate of the | If there is a frequency offset between the frame rate of the | |||
| transport overhead and that of the SONET/SDH SPE, then the alignment | transport overhead and that of the SONET/SDH SPE, then the alignment | |||
| of the SPE shall periodically slip back or advance in time through | of the SPE shall periodically slip back or advance in time through | |||
| positive or negative stuffing. The N and P bits are used to replay | positive or negative stuffing. The N and P bits are used to replay | |||
| the stuff indicators and eliminate transport jitter. | the pointer adjustment events and eliminate transport jitter. | |||
| During a negative pointer adjustment event, the H3 byte from the | ||||
| SONET/SDH stream is incorporated into the CEM packet payload in | ||||
| order with the rest of the SPE. During a positive pointer | ||||
| adjustment event, the stuff byte is not included in the CEM packet | ||||
| payload. | ||||
| The pointer adjustment event MUST be transmitted in three | The pointer adjustment event MUST be transmitted in three | |||
| consecutive packets by the packetizer. The de-packetizer MUST play | consecutive packets by the packetizer. The de-packetizer MUST play | |||
| out the pointer adjustment event when any one packet with N/P bit | out the pointer adjustment event when the first packet of the three | |||
| set is received. | with N/P bit set is received. | |||
| Furthermore, it is possible for pointer adjustments to occur in back | ||||
| to back SONET/SDH frames. In order to support this possibility, the | ||||
| packet size for a particular circuit MUST be no larger than | ||||
| (783*N)/3. Where N is the STS-Nc multiplier. | ||||
| Since the minimum value of N is one, all CEM implementations MUST | ||||
| support a minimum payload length of 783/3 or 261 bytes. Smaller | ||||
| payload lengths MAY be supported as an option. | ||||
| The CEM de-packetizer MUST utilize the CEM sequence numbers to | The CEM de-packetizer MUST utilize the CEM sequence numbers to | |||
| insure that SONET/SDH pointer adjustment events are not played any | insure that SONET/SDH pointer adjustment events are not played any | |||
| more frequently than once per every three CEM packets transmitted by | more frequently than once per every three CEM packets transmitted by | |||
| the remote CEM packetizer. | the remote CEM packetizer. | |||
| If both bits are set, then an AIS-P event has occurred (this is | References [3],[4],and [6] specify that pointer adjustment events | |||
| further discussed in section 7). | MUST be separated by three SONET/SDH frames without a pointer | |||
| adjustment event. In order to relay all legal pointer adjustment | ||||
| events, the packet size for a specific circuit MUST be no larger | ||||
| than (783 * 4 * N)/3, where N is the STS-Nc multiplier. | ||||
| When DBA is invoked (i.e. the D-bit = 1), N and P have additional | However, some SONET/SDH equipment allows pointer adjustments to | |||
| meanings. See Table 1 and section 7. | occur in back to back SONET/SDH frames. In order to support this | |||
| possibility, the packet size for a particular circuit SHOULD be no | ||||
| larger than (783*N)/3. Where N is the STS-Nc multiplier. | ||||
| Since the minimum value of N is one, CEM implementations SHOULD | ||||
| support a minimum payload length of 783/3 or 261 bytes. Smaller | ||||
| payload lengths MAY be supported as an option. | ||||
| 8.2 Asynchronous | 8.2 Asynchronous | |||
| If synchronous timing is not available, the N and P bits are not | If synchronous timing is not available, other methods MAY be | |||
| used for frequency justification and adaptive methods are used to | employed to regenerate the circuit timing. | |||
| recover the timing. The N and P bits are only used for the | ||||
| occurrence of a path AIS event. An example adaptive method can be | For structured CEM, the CEM packetizer SHOULD generate the N and P | |||
| found in section 3.4.2 of [9]. | bits as usual. However, without external synchronization, this | |||
| information is not sufficient to reliably justify the SPE within the | ||||
| SONET/SDH transport framing at the CEM de-packetizer. The de- | ||||
| packetizer MAY employ an adaptive algorithm to introduce pointer | ||||
| adjustment events to map the CEM SPE to the SONET/SDH transport | ||||
| framing. Regardless of whether the N and P bits are used by the de- | ||||
| packetizer as part of the adaptive clock recovery algorithm, they | ||||
| MUST still be used in conjunction with the D-bit to signal AIS-P, | ||||
| SPE Unequipped, and DBA. | ||||
| For unstructured CEM, the CEM de-packetizer MAY use an adaptive | ||||
| clock recovery technique to regenerate the SONET/SDH transport | ||||
| clock. | ||||
| An example adaptive clock recovery method can be found in section | ||||
| 3.4.2 of [10]. | ||||
| 9. CEM LSP Signaling | 9. CEM LSP Signaling | |||
| For maximum network scaling, CEM LSP signaling may be performed | For maximum network scaling in MPLS applications, CEM LSP signaling | |||
| using the LDP Extended Discovery mechanism as augmented by the VC | may be performed using the LDP Extended Discovery mechanism as | |||
| FEC Element defined in [5]. MPLS traffic tunnels may be dedicated | augmented by the VC FEC Element defined in [5]. MPLS traffic | |||
| to CEM, or shared with other MPLS-based services. The value 8008 is | tunnels may be dedicated to CEM, or shared with other MPLS-based | |||
| used for the VC Type in the VC FEC Element in order to signify that | services. The value 8008 is used for the VC Type in the VC FEC | |||
| the LSP being signaled is to carry CEM. Note that the generic | Element in order to signify that the LSP being signaled is to carry | |||
| control word defined in [6] is not used, as its functionality is | CEM. Note that the generic control word defined in [6] is not used, | |||
| included in the CEM encapsulation header. | as its functionality is included in the CEM encapsulation header. | |||
| Alternatively, static label assignment may be used, or a dedicated | Alternatively, static label assignment may be used, or a dedicated | |||
| traffic engineered LSP may be used for each CEM circuit. | traffic engineered LSP may be used for each CEM service. | |||
| CEM packets are fixed in length for all of the packets of a | Normal CEM packets are fixed in length for all of the packets of a | |||
| particular emulated TDM stream. This length is signaled using the | particular emulated TDM stream. This length is signaled using the | |||
| CEM Payload Bytes parameter defined in [5], or is statically | CEM Payload Bytes parameter defined in [5], or is statically | |||
| provisioned for each TDM stream. | provisioned for each CEM service. | |||
| The use of DBA is signaled by the use of the CEM Options parameter | At this time, other aspects of the CEM service MUST be statically | |||
| defined in [5], or is statically provisioned for each TDM stream. | provisioned. The CEM-MIB [11] provides a method for statically | |||
| provisioning CEM services. | ||||
| In [5], Parameter ID 0x05 is allocated for †CEM OptionsË. At this | ||||
| time, the CEM Options parameter is reserved and MUST be set to zero. | ||||
| The use of the CEM Options parameter is for future consideration. | ||||
| 10. Open Issues | 10. Open Issues | |||
| Future revisions of this document may discuss the following items. | Future revisions of this document may discuss the following items. | |||
| Underlying MPLS QoS requirements are not covered by this revision of | Underlying MPLS QoS requirements are not covered by this revision of | |||
| the draft. Future revisions may discuss underlying QoS | the draft. Future revisions may discuss underlying QoS | |||
| requirements. | requirements. | |||
| Support for VT and lower speed non-SONET/SDH services are not | Support for VT and lower speed non-SONET/SDH services are not | |||
| covered in this revision of the draft. Future revisions may address | covered in this revision of the draft. Future revisions may address | |||
| VT and non-SONET/SDH TDM services. | VT and non-SONET/SDH TDM services. | |||
| The current draft only considers DBA based on SONET/SDH Overhead. | Use of the CEM Options parameter in [5] is currently undefined. | |||
| It would be very desirable to extending DBA to include pattern-based | Future revision of this draft will determine how the CEM Options | |||
| suppression such as long runs of HDLC flags (i.e. 0x7E). One issue | word will be used. | |||
| that complicates pattern-based DBA is that the path overhead appears | ||||
| every Nx87 bytes within the SPE. One solution may be to have a | ||||
| special mode of DBA, where the Path Overhead is explicitly | ||||
| transported within the packet along with the specific pattern (e.g. | ||||
| 7E). | ||||
| This revision of the draft does not provide a definition for æloss | The CEM-MIB[11] calls out a number of CEM performance parameters | |||
| of packet synchronizationÆ or æjitter buffer under-runÆ. Details | such as Errored Seconds, Severely Errored Seconds, and Unavailable | |||
| for declaring these conditions at the de-packetizer will be | Seconds. These terms are currently not defined in this draft. The | |||
| addressed in future revisions. | definition of these terms is for future consideration. | |||
| The current draft only considers DBA based on SONET/SDH Overhead. | ||||
| It may be desirable to extending DBA to include pattern-based | ||||
| suppression such as long runs of HDLC flags (i.e. 0x7E). | ||||
| 11. Security Considerations | 11. Security Considerations | |||
| As with [5], this document does not affect the underlying security | As with [5], this document does not affect the underlying security | |||
| issues of MPLS. | issues of MPLS. | |||
| 12. Intellectual Property Disclaimer | 12. Intellectual Property Disclaimer | |||
| This document is being submitted for use in IETF standards | This document is being submitted for use in IETF standards | |||
| discussions. Vivace Networks, Inc. has filed one or more patent | discussions. Vivace Networks, Inc. has filed one or more patent | |||
| skipping to change at page 15, line 29 ¶ | skipping to change at page 18, line 29 ¶ | |||
| Levels", BCP 14, RFC 2119, March 1997 | Levels", BCP 14, RFC 2119, March 1997 | |||
| [3] American National Standards Institute, "Synchronous Optical | [3] American National Standards Institute, "Synchronous Optical | |||
| Network (SONET) - Basic Description including Multiplex | Network (SONET) - Basic Description including Multiplex | |||
| Structure, Rates and Formats," ANSI T1.105-1995. | Structure, Rates and Formats," ANSI T1.105-1995. | |||
| [4] ITU Recommendation G.707, "Network Node Interface For The | [4] ITU Recommendation G.707, "Network Node Interface For The | |||
| Synchronous Digital Hierarchy", 1996. | Synchronous Digital Hierarchy", 1996. | |||
| [5] Martini et al, "Transport of Layer 2 Frames Over MPLS", draft- | [5] Martini et al, "Transport of Layer 2 Frames Over MPLS", draft- | |||
| martini-l2circuit-trans-mpls-05.txt, work in progress, February | martini-l2circuit-trans-mpls-06.txt, work in progress, July | |||
| 2001. | 2001. | |||
| [6] Telcordia Technologies, ôSynchronous Optical Network (SONET) | [6] Telcordia Technologies, ŸSynchronous Optical Network (SONET) | |||
| Transport Systems: Common Generic Criteriaö, GR-253-CORE, Issue | Transport Systems: Common Generic Criteria÷, GR-253-CORE, Issue | |||
| 3, September 2000. | 3, September 2000. | |||
| [7] Martini et al, "Encapsulation Methods for Transport of Layer 2 | [7] Martini et al, "Encapsulation Methods for Transport of Layer 2 | |||
| Frames Over MPLS", draft-martini-l2circuit-encap-mpls-01.txt, | Frames Over MPLS", draft-martini-l2circuit-encap-mpls-02.txt, | |||
| work in progress, February 2001. | work in progress, July 2001. | |||
| [8] Worster, ôMPLS Label Stack Encapsulation in IPö, draft-worster- | [8] Worster, ŸMPLS Label Stack Encapsulation in IP÷, draft-worster- | |||
| mpls-in-ip-04, work in progress, Expires August 2001. | mpls-in-ip-05, work in progress, July 2001. | |||
| [9] ATM Forum, "Circuit Emulation Service Interoperability | [9] ITU-T, ŸRecommendation I.363.1, B-ISDN Adaptation Layer | |||
| Specification: Type AAL1÷, Appendix III, August 1996. | ||||
| [10] ATM Forum, "Circuit Emulation Service Interoperability | ||||
| Specification Version 2.0", af-vtoa-0078.000, January 1997. | Specification Version 2.0", af-vtoa-0078.000, January 1997. | |||
| 13. Acknowledgments | [11] Danenberg et al, "SONET/SDH Circuit Emulation Service Over MPLS | |||
| (CEM) Management Information Base Using SMIv2", draft- | ||||
| danenberg-pw-cem-mib-01.txt, work in progress, July 2001. | ||||
| 14. Acknowledgments | ||||
| The authors would like to thank Mitri Halabi and Bob Colvin, both of | The authors would like to thank Mitri Halabi and Bob Colvin, both of | |||
| Vivace Networks, for their comments and suggestions. | Vivace Networks, for their comments and suggestions. | |||
| 14. Authors' Addresses | 15. Authors' Addresses | |||
| Andrew G. Malis | Andrew G. Malis | |||
| Vivace Networks, Inc. | Vivace Networks, Inc. | |||
| 2730 Orchard Parkway | 2730 Orchard Parkway | |||
| San Jose, CA 95134 | San Jose, CA 95134 | |||
| Email: Andy.Malis@vivacenetworks.com | Email: Andy.Malis@vivacenetworks.com | |||
| Ken Hsu | Ken Hsu | |||
| Vivace Networks, Inc. | Vivace Networks, Inc. | |||
| 2730 Orchard Parkway | 2730 Orchard Parkway | |||
| San Jose, CA 95134 | San Jose, CA 95134 | |||
| Email: Ken.Hsu@vivacenetworks.com | Email: Ken.Hsu@vivacenetworks.com | |||
| skipping to change at page 16, line 40 ¶ | skipping to change at page 19, line 46 ¶ | |||
| Sewickley, PA 15143 | Sewickley, PA 15143 | |||
| Email: jshirron@laurelnetworks.com | Email: jshirron@laurelnetworks.com | |||
| Luca Martini | Luca Martini | |||
| Level 3 Communications, LLC. | Level 3 Communications, LLC. | |||
| 1025 Eldorado Blvd. | 1025 Eldorado Blvd. | |||
| Broomfield, CO 80021 | Broomfield, CO 80021 | |||
| Email: luca@level3.net | Email: luca@level3.net | |||
| Thomas K. Johnson | Thomas K. Johnson | |||
| Litchfield Communications | Litchfield Communications, Inc. | |||
| 76 Westbury Park Rd. | 76 Westbury Park Rd. | |||
| Watertown, CT 06795 | Watertown, CT 06795 | |||
| Email: tom_johnson@litchfieldcomm.com | Email: tom_johnson@litchfieldcomm.com | |||
| Ed Hallman | Ed Hallman | |||
| Litchfield Communications | Litchfield Communications, Inc. | |||
| 76 Westbury Park Rd. | 76 Westbury Park Rd. | |||
| Watertown, CT 06795 | Watertown, CT 06795 | |||
| Email: ed_hallman@litchfieldcomm.com | Email: ed_hallman@litchfieldcomm.com | |||
| Marlene Drost | Marlene Drost | |||
| Litchfield Communications | Litchfield Communications, Inc. | |||
| 76 Westbury Park Rd. | 76 Westbury Park Rd. | |||
| Watertown, CT 06795 | Watertown, CT 06795 | |||
| Email: marlene_drost@litchfieldcomm.com | Email: marlene_drost@litchfieldcomm.com | |||
| Appendix A. SONET/SDH Rates and Formats | Appendix A. SONET/SDH Rates and Formats | |||
| For simplicity, the discussion in this section uses SONET | For simplicity, the discussion in this section uses SONET | |||
| terminology, but it applies equally to SDH as well. SDH-equivalent | terminology, but it applies equally to SDH as well. SDH-equivalent | |||
| terminology is shown in the tables. | terminology is shown in the tables. | |||
| The basic SONET modular signal is the synchronous transport signal- | The basic SONET modular signal is the synchronous transport signal- | |||
| skipping to change at page 17, line 23 ¶ | skipping to change at page 21, line 23 ¶ | |||
| (SPEs). The optical counterpart of the STS-N is the Optical Carrier- | (SPEs). The optical counterpart of the STS-N is the Optical Carrier- | |||
| level N, or OC-N. Table 2 lists standard SONET line rates discussed | level N, or OC-N. Table 2 lists standard SONET line rates discussed | |||
| in this document. | in this document. | |||
| OC Level OC-1 OC-3 OC-12 OC-48 OC-192 | OC Level OC-1 OC-3 OC-12 OC-48 OC-192 | |||
| SDH Term - STM-1 STM-4 STM-16 STM-64 | SDH Term - STM-1 STM-4 STM-16 STM-64 | |||
| Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 | Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 | |||
| Table 2. Standard SONET Line Rates | Table 2. Standard SONET Line Rates | |||
| Each SONET frame is 125 ´s and consists of nine rows. An STS-N frame | Each SONET frame is 125 ³s and consists of nine rows. An STS-N frame | |||
| has nine rows and N*90 columns. Of the N*90 columns, the first N*3 | has nine rows and N*90 columns. Of the N*90 columns, the first N*3 | |||
| columns are transport overhead and the other N*87 columns are SPEs. | columns are transport overhead and the other N*87 columns are SPEs. | |||
| A number of STS-1s may also be linked together to form a super-rate | A number of STS-1s may also be linked together to form a super-rate | |||
| signal with only one SPE. The optical super-rate signal is denoted | signal with only one SPE. The optical super-rate signal is denoted | |||
| as OC-Nc, which has a higher payload capacity than OC-N. | as OC-Nc, which has a higher payload capacity than OC-N. | |||
| The first 9-byte column of each SPE is the path overhead (POH) and | The first 9-byte column of each SPE is the path overhead (POH) and | |||
| the remaining columns form the payload capacity with fixed stuff | the remaining columns form the payload capacity with fixed stuff | |||
| (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 | (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 | |||
| columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed | columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed | |||
| skipping to change at page 18, line 16 ¶ | skipping to change at page 22, line 16 ¶ | |||
| SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c | SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c | |||
| Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 | Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 | |||
| Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 | Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 | |||
| SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 | SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 | |||
| SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 | SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 | |||
| Table 2. Payload Size and Rate | Table 2. Payload Size and Rate | |||
| To support circuit emulation, the entire SPE of a SONET STS or SDH | To support circuit emulation, the entire SPE of a SONET STS or SDH | |||
| VC level is encapsulated into packets, using the encapsulation | VC level is encapsulated into packets, using the encapsulation | |||
| defined in section 5, for carriage across MPLS networks. | defined in section 5, for carriage across packet-switched networks. | |||
| Appendix B. ECC-6 Definition | Appendix B. ECC-6 Definition | |||
| ECC-6 is an Error Correction Code to protect the CEM header. This | ECC-6 is an Error Correction Code to protect the CEM header. This | |||
| provides single bit correction and the ability to detect up to two | provides single bit correction and the ability to detect up to two | |||
| bit errors. | bit errors. | |||
| Error Correction Code: | Error Correction Code: | |||
| |---------------Header bits 0-25 -------------------| ECC-6 code| | |---------------Header bits 0-25 -------------------| ECC-6 code| | |||
| skipping to change at page 19, line 20 ¶ | skipping to change at page 23, line 20 ¶ | |||
| } | } | |||
| } | } | |||
| In other words, for each CEM header bit (i) set to 1, set the | In other words, for each CEM header bit (i) set to 1, set the | |||
| resulting matrix column Y[i] according to Figure 7. | resulting matrix column Y[i] according to Figure 7. | |||
| The final ECC-6 code is calculated as even parity of each row in Y | The final ECC-6 code is calculated as even parity of each row in Y | |||
| (i.e. ECC[k]=CEM[25+k]=even parity of row k). | (i.e. ECC[k]=CEM[25+k]=even parity of row k). | |||
| The receiver also uses matrix X to calculate an intermediate matrix | The receiver also uses matrix X to calculate an intermediate matrix | |||
| YÆ based on all 32 bits of the CEM header. Therefore YÆ is 32 | YË based on all 32 bits of the CEM header. Therefore YË is 32 | |||
| columns wide and includes the ECC-6 code. | columns wide and includes the ECC-6 code. | |||
| for i = 0 to 31 { | for i = 0 to 31 { | |||
| if CEM[i] = 0 { | if CEM[i] = 0 { | |||
| YÆ[i] = 0; | YË[i] = 0; | |||
| } else { | } else { | |||
| YÆ[i] = X[i]; | YË[i] = X[i]; | |||
| } | } | |||
| } | } | |||
| The receiver then appends the incoming ECC-6 code to Y as column 32 | The receiver then appends the incoming ECC-6 code to Y as column 32 | |||
| (ECC[0] should align with row 0) and calculates even parity for each | (ECC[0] should align with row 0) and calculates even parity for each | |||
| row. The result is a single 6 bit column Z. If all 6 bits are 0, | row. The result is a single 6 bit column Z. If all 6 bits are 0, | |||
| there are no bit errors (or at least no detectable errors). | there are no bit errors (or at least no detectable errors). | |||
| Otherwise, it uses Z to perform a reverse lookup on X[] from Figure | Otherwise, it uses Z to perform a reverse lookup on X[] from Figure | |||
| 7. If Z matches column X[i], then there is a single bit error. The | 7. If Z matches column X[i], then there is a single bit error. The | |||
| receiver should invert bit CEM[i] to correct the header. If Z fails | receiver should invert bit CEM[i] to correct the header. If Z fails | |||
| End of changes. 84 change blocks. | ||||
| 206 lines changed or deleted | 343 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||