idnits 2.17.1 draft-ietf-pwe3-cesopsn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1206. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PWE3-SAToP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6555 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3931' is mentioned on line 1065, but not defined == Unused Reference: 'RFC 2401' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'G.702' is defined on line 1263, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2833 (Obsoleted by RFC 4733, RFC 4734) ** Downref: Normative reference to an Informational RFC: RFC 3086 ** Downref: Normative reference to an Informational RFC: RFC 3916 ** Downref: Normative reference to an Informational RFC: RFC 4197 ** Downref: Normative reference to an Informational RFC: RFC 3985 -- Possible downref: Non-RFC (?) normative reference: ref. 'RTP-TYPES' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.702' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.704' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.706' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.775' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.826' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM-CES' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-NWT-170' ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-02 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-07 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-tdm-control-protocol-extensi-01 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-tdm-02 Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Vainshtein - Editor (Axerra Networks) 3 INTERNET-DRAFT I. Sasson (Axerra Networks) 4 Expiration Date: E. Metz (TNO Telecom) 5 November 2006 T. Frost (Zarlink Semiconductor) 6 P. Pate (Overture Networks) 8 May 2006 10 Structure-aware TDM Circuit Emulation Service over Packet Switched 11 Network (CESoPSN) 13 draft-ietf-pwe3-cesopsn-07.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware have 19 been or will be disclosed, and any of which he or she becomes aware 20 will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 ABSTRACT 39 This document describes a method for encapsulating structured (NxDS0) 40 Time Division Multiplexed (TDM)signals as pseudo-wires over packet- 41 switching networks (PSN). In this regard, it complements similar work 42 for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. 44 TABLE OF CONTENTS 46 1. Introduction......................................................2 47 2. Terminology and Reference Models..................................3 48 2.1. Terminology...................................................3 49 2.2. Reference Models..............................................3 50 2.3. Requirements and Design Constraint............................4 51 3. Emulated Services.................................................4 52 4. CESoPSN Encapsulation Layer.......................................5 53 4.1. CESoPSN Packet Format.........................................5 54 4.2. PSN and Multiplexing Layer Headers............................7 55 4.3. CESoPSN Control Word..........................................8 56 4.4. Usage of the RTP header......................................10 57 5. CESoPSN Payload Layer............................................11 58 5.1. Common Payload Format Considerations.........................11 59 5.2. Basic NxDS0 Services.........................................11 60 5.3. Extending Basic NxDS0 Services with CE Application Signaling.13 61 5.4. Trunk-Specific NxDS0 Services with CAS.......................14 62 6. CESoPSN Operation................................................16 63 6.1. Common Considerations........................................16 64 6.2. IWF operation................................................17 65 6.2.1. PSN-bound Direction......................................17 66 6.2.2. CE-bound Direction.......................................17 67 6.3. CESoPSN Defects..............................................19 68 6.4. CESoPSN PW Performance Monitoring............................20 69 7. QoS Issues.......................................................21 70 8. Congestion Control...............................................21 71 9. Security Considerations..........................................22 72 10. IANA Considerations.............................................23 73 11. Applicability Statement.........................................23 74 12. Disclaimer of Validity..........................................24 75 13. NORMATIVE REFERENCES............................................25 76 14. INFORMATIVE REFERENCES..........................................26 77 ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM..........28 78 Annex B. Reference PE Architecture for Emulation of NxDS0 SERvices..29 79 Annex C. Old Mode of CESoPSN Encapsulation over L2TPv3..............31 81 1. Introduction 83 This document describes a method for encapsulating structured (NxDS0) 84 Time Division Multiplexed (TDM) signals as pseudo-wires over packet- 85 switching networks (PSN). In this regard, it complements similar work 86 for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. 88 Emulation of NxDS0 circuits provides for saving PSN bandwidth, supports 89 DS0-level grooming and distributed cross-connect applications. It also 90 enhances resilience of CE devices to effects of loss of packets in the 91 PSN. 93 The CESoPSN solution presented in this document fits the PWE3 94 architecture described in [RFC3985], satisfies the general requirements 95 put forward in [RFC3916] and specific requirements for structured TDM 96 emulation put forward in [RFC4197]. 98 2. Terminology and Reference Models 100 2.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 The terms defined in [RFC3985], Section 1.4 and in [RFC4197], Section 107 3, are consistently used without additional explanations. 109 This document uses some terms and acronyms that are commonly used in 110 conjunction with the TDM services. In particular: 112 o Loss of Signal (LOS) is a common term denoting a condition 113 where a valid TDM signal cannot be extracted from the 114 physical layer of the trunk. Actual criteria for detecting 115 and clearing LOS are described in [G.775] 116 o Frame Alignment Signal (FAS) is a common term denoting a 117 special periodic pattern that is used to impose TDM 118 structures on E1 and T1 circuits. These patterns are 119 described in [G.704] 120 o Out of Frame Synchronization (OOF) is a common term 121 denoting the state of the receiver of a TDM signal when it 122 failed to find valid FAS. Actual criteria for declaring and 123 clearing OOF are described in [G.706]. Handling of this 124 condition includes invalidation of the TDM data 125 o Alarm Indication Signal (AIS) is a common term denoting a 126 special bit pattern in the TDM bit stream that indicates 127 presence of an upstream circuit outage. Actual criteria for 128 declaring and clearing the AIS condition in a TDM stream 129 are defined in [G.775] 130 o Remote Alarm Indication (RAI) and Remote Defect Indication 131 (RDI) are common terms (often used as synonyms) denoting a 132 special pattern in the framing of a TDM service that is 133 sent back by the receiver that experiences an AIS 134 condition. This condition cannot be detected while a LOS, 135 OOF or AIS condition is detected. Specific rules for 136 encoding this pattern in the TDM framing are discussed in 137 [G.775]. 139 We also use the term Interworking Function (IWF) to describe 140 the functional block that segments and encapsulates TDM into 141 CESoPSN packets and in the reverse direction decapsulates 142 CESoPSN packets and reconstitutes TDM. 144 2.2. Reference Models 146 Generic models that have been defined in Sections 4.1, 4.2 and 4.4 of 147 [RFC3985] are fully applicable for the purposes of this document 148 without any modifications. 150 The Network Synchronization reference model and deployment scenarios 151 for emulation of TDM services have been described in [RFC4197], Section 152 4.3. 154 Structured services considered in this document represent special cases 155 of the structured bit stream payload type defined in Section 3.3.4 of 156 [RFC3985]. In each specific case the basic service structures that are 157 preserved by a CESoPSN PW are explicitly specified (see Section 3 158 below). 160 In accordance with the principle of minimum intervention ([RFC3985], 161 Section 3.3.5) the TDM payload is encapsulated without any changes. 163 2.3. Requirements and Design Constraint 165 The CESoPSN protocol has been designed in order to meet the following 166 design constrains: 168 1. Fixed amount of TDM data per packet: All the packets belonging to a 169 given CESoPSN PW MUST carry the same amount of TDM data. This 170 approach simplifies compensation of a lost PW packet with a packet 171 carrying exactly the same amount of "replacement" TDM data 172 2. Fixed end-to-end delay: CESoPSN implementations SHOULD provide the 173 same end-to-end delay between a given pair of CEs regardless of the 174 bit-rate of the emulated service. 175 3. Packetization latency range: 176 a) All the implementations of CESoPSN SHOULD support packetization 177 latencies in the range 1 to 5 milliseconds 178 b) CESoPSN implementations that support configurable packetization 179 latency MUST allow configuration of this parameter with the 180 granularity which is a multiple of 125 microseconds 181 4. Common data path for services with and without CE application 182 signaling (e.g., Channel-Associated Signaling (CAS), see 183 [RFC4197]): if, in addition to TDM data, CE signaling must be 184 transferred between a pair of CE devices for the normal operation 185 of the emulated service, this signaling is passed in dedicated 186 signaling packets specific for the signaling protocol while format 187 and processing of the packets carrying TDM data remains unchanged. 189 3. Emulated Services 191 In accordance with [RFC4197], structured services considered in this 192 specification are NxDS0 services with and without CAS. 194 NxDS0 services are usually carried within appropriate physical trunks, 195 and PEs providing their emulation include appropriate Native Service 196 Processing (NSP) blocks commonly referred to as Framers. 198 The NSPs may also act as digital cross-connects, creating structured 199 TDM services from multiple synchronous trunks. As a consequence, the 200 service may contain more timeslots that could be carried over any 201 single trunk, or the timeslots may not originate from any single trunk. 203 The reference PE architecture supporting these services is described in 204 Annex B. 206 This document defines a single format for packets carrying TDM data 207 regardless of the need to carry CAS or any other CE application 208 signaling. The resulting "basic NxDS0 service" can be extended to carry 209 CE application signaling (e.g. CAS) using separate signaling packets. 210 Signaling packets MAY be carried in the same PW as the packets carrying 211 TDM data or in a separate dedicated PW. 213 In addition, this document also defines dedicated formats for carrying 214 NxDS0 services with CAS in signaling sub-structures in some of the 215 packets. These formats effectively differ for NxDS0 services that 216 originated in different trunks so that their usage results in emulating 217 trunk-specific NxDS0 services with CAS. 219 4. CESoPSN Encapsulation Layer 220 4.1. CESoPSN Packet Format 222 The CESoPSN header MUST contain the CESoPSN Control Word (4 bytes) and 223 MAY also contain a fixed RTP header [RFC3550]. If the RTP header is 224 included in the CESoPSN header, it MUST immediately follow the CESoPSN 225 control word in all cases except UDP demultiplexing, where it 226 MUST precede it (see Fig. 1a, Fig. 1b and Fig. 1c below). 228 Note: The difference in the CESoPSN packet formats for IP PSN using 229 UDP-based demultiplexing and the rest of the PSN and demultiplexing 230 combinations is based on the following considerations: 232 1. Compliance with the existing header compression mechanisms for 233 IPv4/IPv6 PSNs with UDP demultiplexing requires placing the RTP 234 header immediately after the UDP header 235 2. Compliance with the common PWE3 mechanisms for keeping PWs ECMP- 236 safe for the MPLS PSN by providing for PW-IP packet discrimination 237 (see [RFC3985], Section 5.4.3). This requires placing the PWE3 238 control word immediately after the PW label 239 3. Commonality of the CESoPSN packet formats for MPLS networks and 240 IPv4/IPv6 networks with L2TPv3 demultiplexing facilitates smooth 241 stitching of L2TPv3-based and MPLS-based segments of CESoPSN PWs 242 (see [PWE3-MS]). 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | ... | 248 | IPv4/IPv6 and UDP (demultiplexing layer) headers | 249 | ... | 250 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 251 | OPTIONAL | 252 +-- --+ 253 | | 254 +-- --+ 255 | Fixed RTP Header (see [RFC3550]) | 256 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 257 | CESoPSN Control Word | 258 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 259 | Packetized TDM data (Payload) | 260 | ... | 261 | ... | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 1a. CESoPSN Packet Format for an IPv4/IPv6 PSN with 265 UDP demultiplexing 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | ... | 271 | MPLS Label Stack | 272 | ... | 273 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 274 | CESoPSN Control Word | 275 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 276 | OPTIONAL | 277 +-- --+ 278 | | 279 +-- --+ 280 | Fixed RTP Header (see [RFC3550]) | 281 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 282 | Packetized TDM data (Payload) | 283 | ... | 284 | ... | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1b. CESoPSN Packet Format for an MPLS PSN 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | ... | 292 | IPv4/IPv6 and L2TPv3 (demultiplexing layer) headers | 293 | ... | 294 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 295 | CESoPSN Control Word | 296 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 297 | OPTIONAL | 298 +-- --+ 299 | | 300 +-- --+ 301 | Fixed RTP Header (see [RFC3550]) | 302 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 303 | Packetized TDM data (Payload) | 304 | ... | 305 | ... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 1c. CESoPSN Packet Format for an IPv4/IPv6 PSN with 309 L2TPv3 Demultiplexing 311 4.2. PSN and Multiplexing Layer Headers 313 The total size of a CESoPSN packet for a specific PW MUST NOT exceed 314 path MTU between the pair of PEs terminating this PW. 316 CESoPSN implementations working with IPv4 PSN MUST set the "Don't 317 Fragment" flag in IP headers of the packets they generate. 319 Usage of MPLS and L2TPv3 as demultiplexing layers is explained in 320 [RFC3985] and [RFC3931 ] respectively. 322 Setup and maintenance of CESoPSN PWs over MPLS PSN is described in 323 [PWE3-TDM-CONTROL]. 325 Setup and maintenance of CESoPSN PWs over IPv4/IPv6 using L2TPv3 326 demultiplexing is defined in [L2TPEXT-TDM]. 328 When using UDP as the multiplexing mechanism for PWs, manual 329 configuration of both source and destination UDP ports MUST be used. 331 In addition, CESoPSN assumes that UDP-based demultiplexing is aligned 332 with traditional demultiplexing of peer-to-peer applications, i.e.: 334 1. Each CESoPSN IWF instance is associated with ("local association"): 335 a) One of the routable IP addresses of its containing PE. This IP 336 address is treated as the local end-point of the PSN tunnel 337 b) A unique (within the scope defined by this address) UDP port 338 number that is used as the local demultiplexor of the CESoPSN PW 339 packets within the corresponding PSN tunnel 340 2. Each CESoPSN IWF instance is aware (e.g., by configuration) of the 341 similar association of its remote peer ("remote association") and, 342 in each packet it generates, uses: 343 a) The IP address and the UDP port number of its "remote" 344 association as correspondingly the Destination IP address and 345 UDP port 346 b) The IP address and the UDP port number of its "local" 347 association as correspondingly the Source IP address and UDP 348 port. 350 4.3. CESoPSN Control Word 352 The structure of the CESoPSN Control Word that MUST be used with all 353 combinations of the PSN and demultiplexing mechanisms described in the 354 previous section is shown in Fig. 2 below. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 |0|0|0|0|L|R| M |FRG| LEN | Sequence number | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 2. Structure of the CESoPSN Control Word 364 The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST 365 be set to zero unless they are being used to indicate the start of an 366 Associated Channel Header (ACH). An ACH is needed if the state of the 367 CESoPSN PW is being monitored using Virtual Circuit Connectivity 368 Verification [PWE3-VCCV]. 369 L - if set, indicates some abnormal condition of the 370 attachment circuit. 371 M - a 2-bit modifier field. In case of L cleared this field 372 allows discrimination of signaling packets and carrying 373 RDI of the attachment circuit across the PSN. In case of L 374 set only the '00' value is currently defined, other values 375 are reserved for future extensions. L and M bits can be 376 treated as a 3-bit code point space that is described in 377 detail in Table 1 below 379 R - if set by the PSN-bound IWF, indicates that its local CE-bound 380 IWF is in the packet loss state, i.e. has lost a pre-configured 381 number of consecutive packets. The R bit MUST be cleared by the 382 PSN-bound IWF once its local CE-bound IWF has exited the packet 383 loss state, i.e. has received a pre-configured number of 384 consecutive packets. 386 |=================================================================| 387 | L | M | Code Point Interpretation | 388 |===|=====|=======================================================| 389 | 0 | 00 | CESoPSN data packet - normal situation. All CESoPSN | 390 | | | implementations MUST recognize this code point. | 391 | | | Payload MUST be played out "as received". | 392 |---|-----|-------------------------------------------------------| 393 | 0 | 01 | Reserved for future extensions. | 394 |---|-----|-------------------------------------------------------| 395 | 0 | 10 | CESoPSN data packet, RDI condition of the AC. All | 396 | | | CESoPSN implementations MUST support this codepoint: | 397 | | | payload MUST be played out "as received", and, if | 398 | | | so configured, the receiving CESoPSN IWF instance | 399 | | | SHOULD be able to command the NSP to force the RDI | 400 | | | condition on the outgoing TDM trunk. | 401 |---|-----|-------------------------------------------------------| 402 | 0 | 11 | Reserved for CESoPSN signaling packets. | 403 |---|-----|-------------------------------------------------------| 404 | 1 | 00 | TDM data is invalid, payload MAY be omitted. All | 405 | | | implementations MUST recognize this code point and | 406 | | | insert appropriate amount of the configured "idle | 407 | | | code" in the outgoing attachment circuit. In addition,| 408 | | | if so configured, the receiving CESoPSN IWF instance | 409 | | | SHOULD be able to force the AIS condition on the | 410 | | | outgoing TDM trunk. | 411 |---|-----|-------------------------------------------------------| 412 | 1 | 01 | Reserved for future extensions | 413 |---|-----|-------------------------------------------------------| 414 | 1 | 10 | Reserved for future extensions | 415 |---|-----|-------------------------------------------------------| 416 | 1 | 11 | Reserved for future extensions | 417 |=================================================================| 419 Table 1. Interpretation of bits L and M in the CESoPSN CW. 421 Notes: 422 1. Bits in the M field are shown in the same order as in Figure 2 423 (i.e., bit 6 of the CW followed by bit 7 of the CW). 424 2. Implementations that do not support the reserved code points MUST 425 silently discard the corresponding packets upon reception. 427 The FRG bits in the CESoPSN control word MUST be cleared for all 428 services excluding trunk-specific NxDS0 with CAS. In case of these 429 services they MAY be used to denote fragmentation of the multiframe 430 structures between CESoPSN packets as described in [PWE3-FRAG], see 431 Section @5.4 below. 433 LEN (bits (10 to 15) MAY be used to carry the length of the CESoPSN 434 packet (defined as the size of the CESoPSN header + the payload size) 435 if it is less than 64 bytes, and MUST be set to zero otherwise. 436 Note: If fixed RTP header is used in the encapsulation, it is 437 considered part of the CESoPSN header. 439 The sequence number is used to provide the common PW sequencing 440 function as well as detection of lost packets. It MUST be generated in 441 accordance with the rules defined in Section 5.1 of [RFC3550] , for the 442 RTP sequence number, i.e.: 443 o Its space is a 16-bit unsigned circular space 444 o Its initial value SHOULD be random (unpredictable) 445 o It MUST be incremented with each CESoPSN data packet sent in the 446 specific PW. 448 4.4. Usage of the RTP header 450 When a fixed RTP header (see [RFC3550], Section 5.1) is used with 451 CESoPSN, its fields are used in the following way: 453 1. V (version) is always set to 2 454 2. P (padding), X (header extension), CC (CSRC count) and M (marker) 455 are always set to 0 456 3. PT (payload type) is used as following: 457 a) One PT value MUST be allocated from the range of dynamic values 458 (see [RTP-TYPES]) for each direction of the PW. The same PT 459 value MAY be reused for both directions of the PW and also 460 reused between different PWs 461 b) The PE at the PW ingress MUST set the PT field in the RTP header 462 to the allocated value 463 c) The PE at the PW egress MAY use the received value to detect 464 malformed packets 465 4. Sequence number in the RTP header MUST be equal to the sequence 466 number in the CESoPSN CW 467 5. Timestamps are used for carrying timing information over the 468 network: 469 a) Their values are generated in accordance with the rules 470 established in [RFC3550] 471 b) Frequency of the clock used for generating timestamps MUST be an 472 integer multiple of 8 kHz. All implementations of CESoPSN MUST 473 support the 8 kHz clock. Other frequencies that are integer 474 multiples of 8 kHz MAY be used if both sides agree to that 475 c) Possible modes of timestamp generation are discussed below 476 6. The SSRC (synchronization source) value in the RTP header MAY be 477 used for detection of misconnections. 479 The RTP header in CESoPSN can be used in conjunction with at least the 480 following modes of timestamp generation: 482 1. Absolute mode: the ingress PE sets timestamps using the clock 483 recovered from the incoming TDM circuit. As a consequence, the 484 timestamps are closely correlated with the sequence numbers. All 485 CESoPSN implementations MUST support this mode 486 2. Differential mode: PE devices connected by the PW have access to 487 the same high-quality synchronization source, and this 488 synchronization source is used for timestamp generation. As a 489 consequence, the second derivative of the timestamp series 490 represents the difference between the common timing source and the 491 clock of the incoming TDM circuit. Support of this mode is 492 OPTIONAL. 494 5. CESoPSN Payload Layer 495 5.1. Common Payload Format Considerations 497 All the services considered in this document are treated as sequences 498 of "basic structures" (see Section 3 above). The payload of a CESoPSN 499 packet always consists of a fixed number of octets filled, octet by 500 octet, with the data contained in the corresponding consequent basic 501 structures preserving octet alignment between these structures and the 502 packet payload boundaries in accordance with the following rules: 504 1. The order of the payload octets corresponds to their order on the 505 TDM AC. 506 2. Consecutive bits coming from the TDM AC fill each payload octet 507 starting from its most significant bit to the least significant 508 one. 509 3. All the CESoPSN packets MUST carry the same amount of valid TDM 510 data in both directions of the PW. In other words, the time that is 511 required to fill a CESoPSN packet with the TDM data must be 512 constant. The PE devices terminating a CESoPSN PW MUST agree on the 513 number of TDM payload octets in the PW packets for both directions 514 of the PW at the time of the PW setup. 516 Notes: 517 1. CESoPSN packets MAY omit invalid TDM data in order to save the PSN 518 bandwidth. If the CESoPSN packet payload is omitted, the L bit in 519 the CESoPSN control word MUST be set 520 2. CESoPSN PWs MAY carry CE signaling information either in separate 521 packets or appended to packets carrying valid TDM data. If 522 signaling information and valid TDM data are carried in the same 523 CESoPSN packet, the amount of the former does not affect the amount 524 of the latter. 526 5.2. Basic NxDS0 Services 528 As mentioned above, the basic structure preserved across the PSN for 529 this service consists of N octets filled with the data of the 530 corresponding NxDS0 channels belonging to the same frame of the 531 originating trunk(s), and the service generates 8000 such structures 532 per second. 534 CESoPSN MUST use alignment of the basic structures with the packet 535 payload boundaries in order to carry the structures across the PSN. 536 This means that: 538 1. The amount of TDM data in a CESoPSN packet MUST be an integer 539 multiple of the basic structure size 540 2. The first structure in the packet MUST start immediately at the 541 beginning of the packet payload. 543 The resulting payload format is shown in Fig. 3 below. 545 0 1 2 3 4 5 6 7 546 --- +-+-+-+-+-+-+-+-+ 547 | Timeslot 1 | 548 +-+-+-+-+-+-+-+-+ 549 | Timeslot 2 | 550 Frame #1 | ... | 551 | Timeslot N | 552 --- +-+-+-+-+-+-+-+-+ 553 | Timeslot 1 | 554 +-+-+-+-+-+-+-+-+ 555 | Timeslot 2 | 556 Frame #2 | ... | 557 | Timeslot N | 558 --- +-+-+-+-+-+-+-+-+ 559 ... | ... | 560 --- +-+-+-+-+-+-+-+-+ 561 | Timeslot 1 | 562 +-+-+-+-+-+-+-+-+ 563 | Timeslot 2 | 564 Frame #m | ... | 565 | Timeslot N | 566 --- +-+-+-+-+-+-+-+-+ 568 Figure 3. The CESoPSN Packet Payload Format for the Basic NxDS0 Service 570 This mode of operation complies with the recommendation in [RFC3985] to 571 use similar encapsulations for structured bit stream and cell generic 572 payload types. 574 Packetization latency, number of timeslots and payload size are linked 575 by the following obvious relationship: 577 L = 8*N*D 579 where: 580 o D is packetization latency, milliseconds 581 o L is packet payload size, octets 582 o N is number of DS0 channels. 584 CESoPSN implementations supporting NxDS0 services MUST support the 585 following set of configurable packetization latency values: 587 o For N = 1: 8 milliseconds (with the corresponding 588 packet payload size of 64 bytes) 589 o For 2 <=N <= 4: 4 millisecond (with the corresponding 590 packet payload size of 32*N bytes) 591 o For N >= 5: 1 millisecond (with the corresponding 592 packet payload size of 8*N octets). 594 Support of 5 ms packetization latency for N = 1 is RECOMMENDED. 596 Usage of any other packetization latency (packet payload size) that is 597 compatible with the restrictions described above is OPTIONAL. 599 5.3. Extending Basic NxDS0 Services with CE Application 600 Signaling 602 Implementations that have chosen to extend the basic NxDS0 service to 603 support CE application state signaling carry encoded CE application 604 state signals in separate signaling packets. 606 The format of the CESoPSN signaling packets over both IPv4/IPv6 and 607 MPLS PSNs for the case when the CE maintains a separate application 608 state per DS0 channel (e.g., CAS for the telephony applications) is 609 shown in Fig. 4a and 4b below respectively. 611 Signaling packets SHOULD be carried in a separate dedicated PW. 612 However, implementations MAY carry them in the same PW as the TDM data 613 packets for the basic NxDS0 service. The methods of "pairing" the PWs 614 carrying TDM data and signaling packets for the same extended NxDS0 615 service are out of scope of this document. 617 Regardless of the way signaling packets are carried across the PSN, the 618 following rules apply: 620 1. The CESoPSN signaling packets MUST: 621 a) Use their own sequence numbers in the control word 622 b) Set the flags in the control word like following: 623 i) L = 0 624 ii) M = '11' 625 iii) R = 0 626 2. If an RTP header is used in the data packets, it MUST be also used 627 in the signaling packets with the following restrictions: 628 a) An additional RTP payload type (from the range of dynamically 629 allocated types) MUST be allocated for the signaling packets. 630 b) In addition, the signaling packets MUST use their own SSRC 631 value. 633 The protocol used to assure reliable delivery of signaling packets is 634 discussed in Annex A. 636 Encoding of CE application state for telephony applications using CAS 637 follows [RFC2833]. 639 Encoding of CE application state for telephony application using CCS 640 will be considered in a separate document. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | ... | 646 | IPv4/IPv6 and multiplexing layer headers | 647 | ... | 648 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 649 | OPTIONAL Fixed | 650 +-- --+ 651 | RTP | 652 +-- --+ 653 | Header (see [RFC3550]) | 654 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 655 | CESoPSN Control Word | 656 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 657 | Encoded CE application state entry for the DS0 channel #1 | 658 +-- --+ 659 | ... | 660 +-- --+ 661 | Encoded CE application state entry for the DS0 channel #N | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 4a. CESoPSN Signaling Packet Format over an IPv4/IPv6 PSN 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | ... | 670 | MPLS Label Stack | 671 | ... | 672 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 673 | CESoPSN Control Word | 674 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 675 | OPTIONAL Fixed | 676 +-- --+ 677 | RTP | 678 +-- --+ 679 | Header (see [RFC3550]) | 680 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 681 | Encoded CE application state entry for the DS0 channel #1 | 682 +-- --+ 683 | ... | 684 +-- --+ 685 | Encoded CE application state entry for the DS0 channel #N | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 4b. CESoPSN Signaling Packet Format over an MPLS PSN 690 5.4. Trunk-Specific NxDS0 Services with CAS 692 The structure preserved by CESoPSN for this group of services is the 693 trunk multiframe sub-divided into the trunk frames, and signaling 694 information is carried appended to the TDM data using the signaling 695 substructures defined in [ATM-CES]. These substructures comprise N 696 consecutive nibbles, so that the i-th nibble carries CAS bits for the 697 i-th DS0 channel, and are padded with a dummy nibble for odd values of 698 N. 700 CESoPSN implementations supporting trunk-specific NxDS0 services with 701 CAS MUST NOT carry more TDM data per packet than is contained in a 702 single trunk multiframe. 704 All CESoPSN implementations supporting trunk-specific NxDS0 with CAS 705 MUST support the default mode where a single CESoPSN packet carries 706 exactly the amount of TDM data contained in exactly one trunk 707 multiframe and appended with the signaling sub-structure. The TDM data 708 is aligned with the packet payload. In this case: 709 1. Packetization latency is: 710 a) 2 milliseconds for E1 NxDS0 711 b) 3 milliseconds for T1 NxDS0 712 2. The packet payload size is: 713 a) 16*n + floor((N+1)/2) for E1-NxDS0 714 b) 24*n + floor((N+1)/2) for T1/ESF-NxDS0 and T1/SF- 715 NxDS0 716 3. The packet payload format coincides with the multiframe 717 structure described in [ATM-CES] (Section 2.3.1.2). 719 In order to provide lower packetization latency, CESoPSN 720 implementations for trunk-specific NxDS0 with CAS SHOULD support 721 fragmentation of multiframe structures between multiple CESoPSN 722 packets. In this case: 724 1. The FRG bits MUST be used to indicate first, intermediate and last 725 fragment of a multiframe as described in [PWE3-FRAG] 726 2. The amount of the TDM data per CESoPSN packet must be constant. 727 3. Each multiframe fragment MUST comprise an integer multiple of the 728 trunk frames 729 4. The signaling substructure MUST be appended to the last fragment of 730 each multiframe. 732 Format of CESoPSN packets carrying trunk-specific NxDS0 service with 733 CAS that do and do not contain signaling substructures is shown in Fig. 734 5 (a) and (b) respectively. In these figures the number of the trunk 735 frames per multiframe fragment ("m") MUST be an integer divisor of the 736 number of frames per trunk multiframe. 738 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 739 --- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+ 740 | Timeslot 1 | | Timeslot 1 | 741 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 742 | Timeslot 2 | | Timeslot 2 | 743 Frame #1 | ... | Frame #1 | ... | 744 | Timeslot N | | Timeslot N | 745 --- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+ 746 | Timeslot 1 | | Timeslot 1 | 747 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 748 | Timeslot 2 | Frame #2 | Timeslot 2 | 749 Frame #2 | ... | | ... | 750 | Timeslot N | | Timeslot N | 751 --- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+ 752 ... | ... | | ... | 753 --- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+ 754 | Timeslot 1 | | Timeslot 1 | 755 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 756 | Timeslot 2 | | Timeslot 2 | 757 Frame #m | ... | Frame #m | ... | 758 | Timeslot N | | Timeslot N | 759 --- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+ 760 Nibbles 1,2 |A B C D|A B C D| 761 +-+-+-+-+-+-+-+-+ 762 Nibbles 3,4 |A B C D|A B C D| 763 +-+-+-+-+-+-+-+-+ 764 Nibble n |A B C D| (pad) | 765 (odd) & pad +-+-+-+-+-+-+-+-+ 767 (a) The packet with (b) The packet without 768 the signaling structure the signaling structure 769 (the last fragment of (not the last fragment 770 the multiframe) of the multiframe) 772 Figure 5. The CESoPSN Packet Payload Format for 773 Trunk-Specific NxDS0 with CAS 775 Notes: 776 1. In case of T1-NxDS0 with CAS, the signaling bits are 777 carried in the TDM data as well as in the signaling 778 substructure. However, the receiver MUST use the CAS bits 779 as carried in the signaling substructures 780 2. In case of trunk-specific NxDS0 with CAS originating in a 781 T1-SF trunk, each nibble of the signaling substructure 782 contains A and B bits from two consecutive trunk 783 multiframes as described in [ATM-CES]. 785 6. CESoPSN Operation 786 6.1. Common Considerations 787 Edge-to-edge emulation of a TDM service using CESoPSN is only possible 788 when the two PW attachment circuits are of the same type (basic NxDS0 789 or one of the trunk-specific NxDS0 with CAS) and bit rate. The service 790 type and bit rate are exchanged at PW setup as described in [RFC4447]. 792 6.2. IWF operation 794 6.2.1. PSN-bound Direction 796 Once the PW is set up, the PSN-bound CESoPSN IWF operates as follows: 798 TDM data is packetized using the configured number of payload bytes per 799 packet. 801 Sequence numbers, flags, and timestamps (if the RTP header is used) are 802 inserted in the CESoPSN headers and, for trunk-specific NxDS0 with CAS, 803 signaling substructures are appended to the packets carrying the last 804 fragment of a multiframe. 806 CESoPSN, multiplexing layer and PSN headers are prepended to the 807 packetized service data. 809 The resulting packets are transmitted over the PSN. 811 6.2.2. CE-bound Direction 813 The CE-bound CESoPSN IWF SHOULD include a jitter buffer where payload 814 of the received CESoPSN packets is stored prior to play-out to the 815 local TDM attachment circuit. The size of this buffer SHOULD be locally 816 configurable to allow accommodation to the PSN-specific packet delay 817 variation. 819 The CE-bound CESoPSN IWF MUST detect lost and mis-ordered packets. It 820 SHOULD use the sequence number in the control word for these purposes 821 but, if the RTP header is used, the RTP sequence number MAY be used 822 instead. 824 The CE-bound CESoPSN IWF MAY re-order mis-ordered packets. Mis-ordered 825 packets that cannot be reordered MUST be discarded and treated as lost. 827 The payload of the received CESoPSN data packets marked with the L bit 828 set SHOULD be replaced by the equivalent amount of some locally 829 configured "idle" bit pattern even if it has not been omitted. In 830 addition, the CE-bound CESoPSN IWF will be locally configured to 831 command its local NSP to perform one of the following actions: 833 o None (MUST be supported by all the implementations) 834 o Transmit the AIS pattern towards the local CE on the E1 or T1 trunk 835 carrying the local attachment circuit (support of this action is 836 RECOMMENDED) 837 o Send the "Channel Idle" signal to the local CE for all the DS0 838 channels comprising the local attachment circuit (support of this 839 action is OPTIONAL). 841 If the data packets received are marked with L bit cleared and M bits 842 set to '10' or with R bit set, the CE-bound CESoPSN IWF will be locally 843 configured to command its local NSP to perform one of the following 844 actions: 846 o None (MUST be supported by all the implementations) 847 o Transmit the RAI pattern towards the local CE on the E1 or T1 trunk 848 carrying the local attachment circuit (support of this action is 849 RECOMMENDED) 850 o Send the "Channel Idle" signal to the local CE for all the DS0 851 channels comprising the local attachment circuit (support of this 852 action is OPTIONAL and requires also that the CE-bound CES IWF 853 replaces the actually received payload with the equivalent amount 854 of the locally configured "idle" bit pattern. 856 Notes: 858 1. If the pair of IWFs at the two ends of the PW have been configured 859 to force the TDM trunks carrying their ACs to transmit AIS upon 860 reception of data packets with the L bit set and to transmit RAI 861 upon reception of data packets with the R bit set or with the L bit 862 cleared and M bits set to '10', this PW provides a bandwidth-saving 863 emulation of a fractional E1 or T1 service between the pair of CE 864 devices 865 2. If the pair of IWFs at the two ends of the PW have been configured 866 to signal "Channel Idle" CE application state to its local CE upon 867 reception of packets marked with L bit set, R bit set or (L,M) set 868 to '010' and to replace the actually received payload with the 869 locally configured "idle" bit pattern, the resulting PW will comply 870 with the requirements for Downstream Trunk conditioning as defined 871 in [TR-NWT-170]. 872 3. Usage of bits R,L and M described above additionally provides the 873 tools for "single-ended" management of the CESoPSN pseudo-wires 874 with ability to distinguish between the problems in the PSN and in 875 the TDM attachment circuits. 877 The payload of each lost CESoPSN data packet MUST be replaced with the 878 equivalent amount of the replacement data. The contents of the 879 replacement data are implementation-specific and MAY be locally 880 configurable. By default, all CESoPSN implementations MUST support 881 generation of the locally configurable "idle" pattern as the 882 replacement data. 884 Before a PW has been set up and after a PW has been torn down, the IWF 885 MUST play out the locally configurable "idle" pattern to its TDM 886 attachment circuit. 888 Once the PW has been set up, the CE-bound IWF begins to receive CESoPSN 889 packets and to store their payload in the jitter buffer but continues 890 to play out the locally configurable "idle" pattern to its TDM 891 attachment circuit. This intermediate state persists until a pre- 892 configured amount of TDM data (usually half of the jitter buffer) has 893 been received in consecutive CESoPSN packets or until a pre-configured 894 intermediate state timer expires. 896 Once the pre-configured amount of the TDM data has been received, the 897 CE-bound CESoPSN IWF enters its normal operation state where it 898 continues to receive CESoPSN packets and to store their payload in the 899 jitter buffer while playing out the contents of the jitter buffer in 900 accordance with the required clock. In this state the CE-bound IWF 901 performs clock recovery, MAY monitor PW defects, and MAY collect PW 902 performance monitoring data. 904 If the CE-bound CESoPSN IWF detects loss of a pre-configured number of 905 consecutive packets or if the intermediate state timer expires before 906 the required amount of TDM data has been received, it enters its packet 907 loss state. While in this state: 909 o The locally configurable "idle" pattern SHOULD be played out to the 910 TDM attachment circuit 911 o The local PSN-bound CESoPSN IWF SHOULD mark every packet it 912 transmits with the R bit set. 914 The CE-bound CESoPSN IWF leaves this state and transits to the 915 normal one once a pre-configured number of consecutive CESoPSN 916 packets have been received. 918 6.3. CESoPSN Defects 920 In addition to the packet loss state of the CE-bound CESoPSN IWF 921 defined above, it MAY detect the following defects: 923 o Stray packets 924 o Malformed packets 925 o Excessive packet loss rate 926 o Buffer overrun 927 o Remote packet loss. 929 Corresponding to each defect is a defect state of the IWF, a detection 930 criterion that triggers transition from the normal operation state to 931 the appropriate defect state, and an alarm that MAY be reported to the 932 management system and thereafter cleared. Alarms are only reported when 933 the defect state persists for a pre-configured amount of time 934 (typically 2.5 seconds) and MUST be cleared after the corresponding 935 defect is undetected for a second pre-configured amount of time 936 (typically 10 seconds). The trigger and release times for the various 937 alarms may be independent. 939 Stray packets MAY be detected by the PSN and multiplexing layers. When 940 RTP is used, the SSRC field in the RTP header MAY be used for this 941 purpose as well. Stray packets MUST be discarded by the CE-bound IWF 942 and their detection MUST NOT affect mechanisms for detection of packet 943 loss. 945 Malformed packets MAY be detected by mismatch between the expected 946 packet size (taking the value of the L bit into account) and the actual 947 packet size inferred from the PSN and multiplexing layers. When RTP is 948 used, lack of correspondence between the PT value and that allocated 949 for this direction of the PW MAY also be used for this purpose. Other 950 methods of detecting malformed packets are implementation-specific. 951 Malformed in-order packets MUST be discarded by the CE-bound IWF and 952 replacement data generated as for lost packets. 954 Excessive packet loss rate is detected by computing the average packet 955 loss rate over a configurable amount of times and comparing it with a 956 pre-configured threshold. 958 Buffer overrun is detected in the normal operation state when the 959 jitter buffer of the CE-bound IWF cannot accommodate newly arrived 960 CESoPSN packets. 962 Remote packet loss is indicated by reception of packets with their R 963 bit set. 965 6.4. CESoPSN PW Performance Monitoring 967 Performance monitoring (PM) parameters are routinely collected for TDM 968 services and provide an important maintenance mechanism in TDM 969 networks. Ability to collect compatible PM parameters for CESoPSN PWs 970 enhances their maintenance capabilities. 972 Collection of the CESoPSN PW performance monitoring parameters is 973 OPTIONAL, and if implemented, is only performed after the CE-bound IWF 974 has exited its intermediate state. 976 CESoPSN defines error events, errored blocks and defects as follows: 978 o A CESoPSN error event is defined as insertion of a single 979 replacement packet into the jitter buffer (replacement of 980 payload of CESoPSN packets with the L bit set is not 981 considered as insertion of a replacement packet) 982 o A CESoPSN errored data block is defined as a block of data 983 played out to the TDM attachment circuit and of size 984 defined in accordance with the [G.826] rules for the 985 corresponding TDM service that has experienced at least one 986 CESoPSN error event 987 o A CESoPSN defect is defined as the packet loss state of the 988 CE-bound CESoPSN IWF. 990 The CESoPSN PW PM parameters (Errored, Severely Errored and Unavailable 991 Seconds) are derived from these definitions in accordance with [G.826]. 993 7. QoS Issues 995 If the PSN providing connectivity between PE devices is Diffserv- 996 enabled and provides a per-domain behavior (PDB) [RFC3086] that 997 guarantees low-jitter and low-loss, the CESoPSN PW SHOULD use this PDB 998 in compliance with the admission and allocation rules the PSN has put 999 in place for that PDB (e.g., marking packets as directed by the PSN). 1001 8. Congestion Control 1003 As explained in [RFC3985], the PSN carrying the PW may be subject to 1004 congestion. CESoPSN PWs represent inelastic constant bit-rate (CBR) 1005 flows and cannot respond to congestion in a TCP-friendly manner 1006 prescribed by [RFC2914], although the percentage of total bandwidth 1007 they consume remains constant. 1009 Unless appropriate precautions are taken, undiminished demand of 1010 bandwidth by CESoPSN PWs can contribute to network congestion that may 1011 impact network control protocols. 1013 Whenever possible, CESoPSN PWs SHOULD be carried across traffic- 1014 engineered PSNs that provide either bandwidth reservation and admission 1015 control or forwarding prioritization and boundary traffic conditioning 1016 mechanisms. IntServ-enabled domains supporting Guaranteed Service (GS) 1017 [RFC2212] and DiffServ-enabled domains [RFC2475] supporting Expedited 1018 Forwarding (EF) [RFC3246] provide examples of such PSNs. Such 1019 mechanisms will negate, to some degree, the effect of the CESoPSN PWs 1020 on the neighboring streams. In order to facilitate boundary traffic 1021 conditioning of CESoPSN traffic over IP PSNs, the CESoPSN IP packets 1022 SHOULD NOT use the DiffServ Code Point (DSCP) value reserved for the 1023 Default PHB[RFC2474]. 1025 If CESoPSN PWs run over a PSN providing best-effort service, they 1026 SHOULD monitor packet loss in order to detect "severe congestion". If 1027 such a condition is detected, a CESoPSN PW SHOULD shut down bi- 1028 directionally for some period of time as described in Section 6.5 of 1029 [RFC3985]. 1031 Note that: 1033 1. The CESoPSN IWF can inherently provide packet loss measurement 1034 since the expected rate of arrival of CESoPSN packets is fixed and 1035 known 1036 2. The results of the CESoPSN packet loss measurement may not be a 1037 reliable indication of presence or absence of severe congestion if 1038 the PSN provides enhanced delivery, e.g.: 1039 a) If CESoPSN traffic takes precedence over non-CESoPSN traffic, 1040 severe congestion can develop without significant CESoPSN packet 1041 loss 1042 b) If non-CESoPSN traffic takes precedence over CESoPSN traffic, 1043 CESoPSN may experience substantial packet loss due to a short- 1044 term burst of high-priority traffic 1045 3. The TDM services emulated by the CESoPSN PWs have high availability 1046 objectives (see [G.826]) that MUST be taken into account when 1047 deciding on temporary shutdown of CESoPSN PWs. 1049 This specification does not define the exact criteria for detecting 1050 "severe congestion" using the CESoPSN packet loss rate or the specific 1051 methods for bi-directional shutdown the CESoPSN PWs (when such severe 1052 congestion has been detected) and their consequent re-start after a 1053 suitable delay. This is left for further study. However, the following 1054 considerations may be used as guidelines for implementing the CESoPSN 1055 severe congestion shutdown mechanism: 1057 1. CESoPSN Performance Monitoring techniques (see Section 6.4) provide 1058 entry and exit criteria for the CESoPSN PW "Unavailable" state that 1059 make it closely correlated with the "Unavailable" state of the 1060 emulated TDM circuit as specified in [G.826]. Using the same 1061 criteria for "severe congestion" detection may decrease the risk of 1062 shutting down the CESoPSN PW while the emulated TDM circuit is 1063 still considered available by the CE. 1064 2. If the CESoPSN PW has been set up using either PWE3 control 1065 protocol [RFC4447] or L2TPv3 [RFC 3931], the regular PW teardown 1066 procedures of these protocols SHOULD be used. 1067 3. If one of the CESoPSN PW end points stops transmission of packets 1068 for a sufficiently long period, its peer (observing 100% packet 1069 loss) will necessarily detect "severe congestion" and also stop 1070 transmission, thus achieving bi-directional PW shutdown. 1072 9. Security Considerations 1074 CESoPSN does not enhance or detract from the security performance of 1075 the underlying PSN; rather it relies upon the PSN mechanisms for 1076 encryption, integrity, and authentication whenever required. 1078 CESoPSN PWs share susceptibility to a number of pseudowire-layer 1079 attacks, and will use whatever mechanisms for confidentiality, 1080 integrity and authentication that are developed for general PWs. These 1081 methods are beyond the scope of this document. 1083 Although CESoPSN PWs MAY employ an RTP header when explicit transfer of 1084 timing information is required, SRTP (see [RFC3711]) mechanisms are NOT 1085 RECOMMENDED as a substitute for PW layer security. 1087 Misconnection detection capabilities of CESoPSN increase its resilience 1088 to misconfiguration and some types of DoS attacks. 1090 Random initialization of sequence numbers, in both the control word and 1091 the optional RTP header, makes known-plaintext attacks on encrypted 1092 CESoPSN PWs more difficult. Encryption of PWs is beyond the scope of 1093 this document. 1095 10. IANA Considerations 1097 Allocation of PW Types for the corresponding CESoPSN PWs is defined in 1098 [RFC4446]. 1100 11. Applicability Statement 1102 CESoPSN is an encapsulation layer intended for carrying NxDS0 services 1103 with or without CAS over PSN. 1105 CESoPSN allows emulation of certain end-to-end delay properties of TDM 1106 networks. In particular, the end-to-end delay of a TDM circuit emulated 1107 by a CESoPSN PW does not depend upon the bit-rate of the service. 1109 CESoPSN fully complies with the principle of minimal intervention 1110 minimizing overhead and computational power required for encapsulation. 1112 CESoPSN can be used in conjunction with various clock recovery 1113 techniques and does not presume availability of a global synchronous 1114 clock at the ends of a PW. However, if the global synchronous clock is 1115 available at both ends of a CESoPSN PW, using RTP and differential mode 1116 of timestamp generation improves the quality of the recovered clock. 1118 CESoPSN allows carrying CE application state signaling that requires 1119 synchronization with data in-band in separate signaling packets. A 1120 special combination of flags in the CESoPSN control word is used to 1121 distinguish between data and signaling packets, while the Timestamp 1122 field in the RTP headers is used for synchronization. This makes 1123 CESoPSN extendable to support different types of CE signaling without 1124 affecting the data path in the PE devices. 1126 CESoPSN also allows emulation of NxDS0 services with CAS carrying the 1127 signaling information appended to (some of) the packets carrying TDM 1128 data. 1130 CESoPSN allows the PSN bandwidth conservation by carrying only AIS 1131 and/or Idle Code indications instead of data. 1133 CESoPSN allows deployment of bandwidth-saving Fractional point-to-point 1134 E1/T1 applications. These applications can be described like following: 1136 o The pair of CE devices operates as if they were connected 1137 by an emulated E1 or T1 circuit. In particular they react 1138 to AIS and RAI states of their local ACs in the standard 1139 way 1140 o The PSN carries only an NxDS0 service where N is the number 1141 of actually used timeslots in the circuit connecting the 1142 pair of CE devices thus saving the bandwidth. 1144 Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP- 1145 friendly behavior under network congestion. If the service encounters 1146 congestion, it SHOULD be temporarily shut down. 1148 CESoPSN allows collection of TDM-like faults and performance monitoring 1149 parameters hence emulating 'classic' carrier services of TDM circuits 1150 (e.g., SONET/SDH). Similarity with these services is increased by the 1151 CESoPSN ability to carry 'far end error' indications. 1153 CESoPSN provides for a carrier-independent ability to detect 1154 misconnections and malformed packets. This feature increases resilience 1155 of the emulated service to misconfiguration and DoS attacks. 1157 CESoPSN provides for detection of lost packets and allows using various 1158 techniques for generation of "replacement packets". 1160 CESoPSN carries indications of outages of incoming attachment circuit 1161 across the PSN thus providing for effective fault isolation. 1163 Faithfulness of a CESoPSN PW may be increased if the carrying PSN is 1164 Diffserv-enabled and implements a PDB that guarantees low loss and low 1165 jitter. 1167 CESoPSN does not provide any mechanisms for protection against PSN 1168 outages. As a consequence, resilience of the emulated service to such 1169 outages is defined by the PSN behavior. On the other hand: 1171 o The jitter buffer and packets' reordering mechanisms 1172 associated with CESoPSN increase resilience of the emulated 1173 service to fast PSN re-convergence events 1174 o Remote indication of lost packets is carried backward 1175 across the PSN from the receiver (that has detected loss of 1176 packets) to transmitter. Such an indication MAY be used as 1177 a trigger for activation of proprietary service-specific 1178 protection mechanisms. 1180 Security of TDM services provided by CESoPSN across a shared PSN may be 1181 below the level of security traditionally associated with TDM services 1182 carried across TDM networks. 1184 12. Disclaimer of Validity 1186 The IETF takes no position regarding the validity or scope of any 1187 Intellectual Property Rights or other rights that might be claimed 1188 to pertain to the implementation or use of the technology 1189 described in this document or the extent to which any license 1190 under such rights might or might not be available; nor does it 1191 represent that it has made any independent effort to identify any 1192 such rights. Information on the procedures with respect to rights 1193 in RFC documents can be found in BCP 78 and BCP 79. 1195 Copies of IPR disclosures made to the IETF Secretariat and any 1196 assurances of licenses to be made available, or the result of an 1197 attempt made to obtain a general license or permission for the use 1198 of such proprietary rights by implementers or users of this 1199 specification can be obtained from the IETF on-line IPR repository 1200 at http://www.ietf.org/ipr. 1202 The IETF invites any interested party to bring to its attention 1203 any copyrights, patents or patent applications, or other 1204 proprietary rights that may cover technology that may be required 1205 to implement this standard. Please address the information to the 1206 IETF at ietf-ipr@ietf.org. 1208 ACKNOWLEDGEMENTS 1210 Akiva Sadovski has been an active participant of the team that co- 1211 authored early versions of this document. 1213 We express deep gratitude to Stephen Casner who reviewed an early 1214 version of this document in detail, corrected some serious errors and 1215 provided many valuable inputs. 1217 The present version of the text of the QoS section has been suggested 1218 by Kathleen Nichols. 1220 We thank Maximilian Riegel, Sim Narasimha, Tom Johnson, Ron Cohen and 1221 Yaron Raz for valuable feedbacks. 1223 We thank Alik Shimelmits for many fruitful discussions. 1225 13. NORMATIVE REFERENCES 1227 [RFC2119] Bradner, S. Key Words in RFCs to Indicate Requirement Levels, 1228 RFC 2119, March 1997 1230 [RFC 2401] Kent S., Atkinson, R., Security Architecture for the 1231 Internet Protocol, RFC 2401, November 1998 1233 [RFC2833] Schulzrinne, H., Petrack, S., RTP Payload for DTMF Digits, 1234 Telephony Tones and Telephony Signals, RFC 2833, May 2000 1236 [RFC2914] Floyd, S., Congestion Control Principles, RFC 2914, September 1237 2000 1239 [RFC3086] Nichols, K., Carpenter, B., Definition of Differentiated 1240 Services Per Domain Behaviors and Rules for their Specification, RFC 1241 3086, April 2001 1243 [RFC3916] Xiao, X., et al, Requirements for Pseudo Wire Emulation Edge- 1244 to-Edge (PWE3), RFC 3916, September 2004 1246 [RFC4197] Riegel, M., Requirements for Edge-to-Edge Emulation of TDM 1247 Circuits over Packet Switching Networks (PSN, RFC 4197, October 2005 1249 [RFC3985] Bryant, S., Pate, P., PWE3 Architecture, RFC 3985, March 2005 1251 [RFC3550] Schulzrinne, H., et al, RTP: A Transport Protocol for Real- 1252 Time Applications, RFC 3550, July 2003 1254 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- 1255 parameters 1257 [RFC4385] Bryant, S., et al, PWE3 Control Word for use over an MPLS PSN 1258 RFC 4385, February 2006 1260 [PWE3-FRAG] Malis, A, Townsley, M., PWE3 Fragmentation and Reassembly, 1261 Work in Progress, November 2005, draft-ietf-pwe3-fragmentation-10.txt 1263 [G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit 1264 Rates 1266 [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame 1267 structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s 1268 hierarchical levels 1270 [G.706] ITU-T Recommendation G.706 (04/91) - Frame Alignment and Cyclic 1271 Redundancy Check (CRC) Procedures Relating to Basic Frame Structured 1272 Defined in Recommendation G.704 1274 [G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), 1275 Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect 1276 Detection and Clearance Criteria for PDH Signals 1278 [G.826] ITU-T Recommendation G.826 (02/99) - Error performance 1279 parameters and objectives for international, constant bit rate digital 1280 paths at or above the primary rate 1282 [T1.107] American National Standard for Telecommunications - Digital 1283 Hierarchy - Format Specifications, ANSI T1.107-1988 1285 [ATM-CES] The ATM Forum Technical Committee. Circuit Emulation Service 1286 Interoperability Specification version 2.0 af-vtoa-0078.000, January 1287 1997. 1289 [TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and 1290 Objectives, Bellcore, TR-NWT-170, January 1993 1292 [RFC4447] Martini L. et al, Pseudowire Setup and Maintenance Using the 1293 Label Distribution Protocol (LDP), RFC 4447, April 2006 1295 14. INFORMATIVE REFERENCES 1297 [RFC4446] Martini, L., Townsley, M., IANA Allocations for pseudo Wire 1298 Edge to Edge Emulation (PWE3), RFC 4446, April 2006 1300 [PWE3-SAToP] Vainshtein, A., Stein, Y., Structure-Agnostic TDM over 1301 Packet (SAToP), Work in Progress, February 2006, draft-ietf-pwe3-satop- 1302 05.txt 1304 [RFC3931 ] Lau, J., Townsley, M., Goyret, I., (editors), Layer Two 1305 Tunneling Protocol (Version 3), RFC 3931, March 2005 1307 [RFC3711] M. Baugher et al, The Secure Real-time Transport Protocol 1308 (SRTP), RFC 3711, 2004 1310 [RFC2212] S. Shenker et al, Specification of Guaranteed Quality of 1311 Service, RFC 2212, 1997 1313 [RFC3246], B. Davie et al, An Expedited Forwarding PHB (Per-Hop 1314 Behavior), RFC 3246, 2002 1316 [RFC2474] K. Nichols et al, Definition of the Differentiated Services 1317 Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, 19998 1319 [RFC2475] S. Blake et al, An Architecture for Differentiated Services, 1320 RFC 2475, 1998 1322 [RFC3246], B. Davie et al, An Expedited Forwarding PHB (Per-Hop 1323 Behavior), RFC 3246, 2002 1325 [PWE3-MS] Martini, L., et al, Segmented Pseudo Wire, Work in Progress, 1326 March 2006, draft-ietf-pwe3-segmented-pw-02.txt 1328 [PWE3-VCCV] Nadeau, T., Aggarwal, R., Pseudo Wire Virtual Circuit 1329 Connectivity Verification (VCCV), Work in Progress, September 2005, 1330 draft-ietf-pwe3-vccv-07.txt 1332 [PWE3-TDM-CONTROL] Vainshtein, A., Stein, Y., Control Protocol 1333 Extensions for Setup of TDM Pseudowires, Work in Progress, March 2006, 1334 draft-ietf-pwe3-tdm-control-protocol-extensi-01.txt 1336 [L2TPEXT-TDM] Galtsur, S., Layer Two Tunneling Protocol - Setup of TDM 1337 Pseudowires, Work in Progress, November 2005, draft-ietf-l2tpext-tdm- 1338 02.txt 1340 Authors' Addresses 1342 Alexander ("Sasha") Vainshtein 1343 Axerra Networks 1344 24 Raoul Wallenberg St., 1345 Tel Aviv 69719, Israel 1346 email: sasha@axerra.com 1348 Israel Sasson 1349 Axerra Networks 1350 24 Raoul Wallenberg St., 1351 Tel Aviv 69719, Israel 1352 email: israel@axerra.com 1354 Eduard Metz 1355 Thrupoint 1356 Paasheuvelweg 16, 1357 email: e.t.metz@telecom.tno.nl 1359 Tim Frost 1360 Zarlink Semiconductor 1361 Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK 1362 email: tim.frost@zarlink.com 1364 Prayson Pate 1365 Overture Networks 1366 507 Airport Boulevard 1367 Building 111 Morrisville, North Carolina, 27560 1368 Email: prayson.pate@overturenetworks.com 1370 Full Copyright Statement 1372 Copyright (C) The Internet Society (2006). 1374 This document is subject to the rights, licenses and restrictions 1375 contained in BCP 78, and except as set forth therein, the authors 1376 retain all their rights. 1378 This document and the information contained herein are provided on an 1379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1386 Acknowledgement 1388 Funding for the RFC Editor function is currently provided by the 1389 Internet Society. 1391 ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM 1393 Format of the CESoPSN signaling packets is discussed in 1394 Section 5.3 above. 1396 The sequence number in the CESoPSN control word for the 1397 signaling packets is generated according to the same rules as 1398 for the TDM data packets. 1400 If the RTP header is used in the CESoPSN signaling packets, 1401 the timestamp in this header represents the time when the CE 1402 application state has been collected. 1404 Signaling packets are generated by the ingress PE in accordance with 1405 the following logic (adapted from [RFC2833]): 1407 1. The CESoPSN signaling packet with the same information 1408 (including the timestamp in the case RTP header is used) is 1409 sent 3 times at an interval of 5 ms under one of the 1410 following conditions: 1411 a) The CESoPSN PW has been set up 1412 b) A change in the CE application state has been 1413 detected. If another change of the CE application 1414 state has been detected during the 10 ms period 1415 (i.e. before all three signaling packets reporting 1416 the previous change have been sent), this process is 1417 re-started, i.e.: 1418 i) The unsent signaling packet(s) with the 1419 previous CE application state are discarded 1420 ii) Triple send of packets with the new CE 1421 application state begins. 1422 c) Loss of packets defect has been cleared 1423 d) Remote Loss of Packets indication has been cleared 1424 (after previously being set) 1425 2. Otherwise, the CESoPSN signaling packet with the current CE 1426 application state information is sent every 5 seconds. 1428 These rules allow fast probabilistic recovery after loss of a single 1429 signaling packet as well as deterministic (but, possibly, slow) 1430 recovery following PW setup and PSN outages. 1432 ANNEX B. REFERENCE PE ARCHITECTURE FOR EMULATION OF NXDS0 SERVICES 1434 Structured TDM services do not exist as physical circuits. They are 1435 always carried within appropriate physical attachment circuits (AC), 1436 and the PE providing their emulation always includes a Native Service 1437 Processing Block (NSP) commonly referred to as Framer. As a 1438 consequence, the architecture of a PE device providing edge-to-edge 1439 emulation for these services includes the Framer and Forwarder blocks. 1441 In case of NxDS0 services (the only type of structured services 1442 considered in this document), the AC is either an E1 or a T1 trunk, and 1443 bundles of NxDS0 are cut out of it using one of the framing methods 1444 described in [G.704]. 1446 In addition to detecting the FAS and imposing associated structure on 1447 the "trunk" AC, E1 and T1 framers commonly support some additional 1448 functionality including: 1450 1. Detection of special states of the incoming AC (e.g., 1451 AIS, OOF or RAI) 1452 2. Forcing special states (e.g., AIS and RAI) on the 1453 outgoing AC upon an explicit request 1454 3. Extraction and insertion of CE application signals 1455 that may accompany specific DS0 channel(s). 1457 The resulting PE architecture for NxDS0 services is shown in Fig. B.1 1458 below. In this diagram: 1460 1. In the PSN-bound direction: 1462 a) The Framer: 1463 i) Detects frame alignment signal (FAS) 1464 and splits the incoming ACs into separate 1465 DS0 channels 1466 ii) Detects special AC states 1467 iii) If necessary, extracts CE application 1468 signals accompanying each of the separate 1469 DS0 services 1470 b) The Forwarder: 1471 i) Creates one or more NxDS0 bundles 1472 ii) Sends the data received in each such 1473 bundle to the PSN-bound direction of a 1474 respective CESoPSN IWF instance 1475 iii) If necessary, sends the current CE 1476 application state data of the DS0 1477 services in the bundle to the PSN-bound 1478 direction of the respective CESoPSN IWF 1479 instance 1480 iv) If necessary sends the AC state 1481 indications to the PSN-bound directions 1482 of all the CESoPSN instances associated 1483 with the given AC 1484 c) Each PSN-bound PW IWF instance encapsulates the 1485 received data, application state signal and the 1486 AC state into PW PDUs and sends the resulting 1487 packets to the PSN 1488 2. In the CE-bound direction: 1489 i) Each CE-bound instance of the CESoPSN 1490 IWF receives the PW PDUs from the PSN, 1491 extracts the TDM data, AC state and CE 1492 application state signals and sends them 1493 b) The Forwarder sends the TDM data, application 1494 state signals and, if necessary, a single 1495 command representing the desired AC state, to 1496 the Framer 1497 c) The Framer accepts all the data of one or more 1498 NxDS0 bundles possibly accompanied by the 1499 associated CE application state and commands 1500 referring to the desired AC state, and 1501 generates a single AC accordingly with correct 1502 FAS. 1504 Notes: This model is asymmetric: 1505 o AC state indication can be forwarded from the framer 1506 to multiple instances of the CESoPSN IWF 1507 o No more than one CESoPSN IWF instance should forward 1508 AC state-affecting commands to the framer. 1510 +------------------------------------------+ 1511 | PE Device | 1512 +------------------------------------------+ 1513 | | Forwarder | | 1514 | |---------------------| | 1515 | | | | 1516 | +<-- AC State---->- | | 1517 | | | | | 1518 | | | | | 1519 E1 or T1 | | | | | 1520 AC | | | | | 1521 <=======>| |-----------------+---|--------------| 1522 | | | | At most one | 1523 | | |-->+ PW IWF | 1524 | | | instance im- | 1525 ... | +<---NxDS0 TDM Data-->+ posing state | PW Instance 1526 | F | | on the X<===========> 1527 | +<---CE App State --->+ outgoing AC | 1528 E1 or T1 | R | | | 1529 AC | +<--AC Command -------+ | 1530 <=======>o A |---------------------|--------------| 1531 | | ... | ... | ... 1532 | M |-----------------+---|--------------| 1533 | | | | Zero, one or | 1534 | E | |-->+ more PW IWF | 1535 | | | instances 1536 | R +<---NxDS0 TDM Data-->+ that do not | PW Instance 1537 | | | impose state X<===========> 1538 | +<---CE App State --->+ on the outgo-| 1539 | | | ing AC | 1540 +------------------------------------------+ 1542 Figure B.1. Reference PE Architecture for NxDS0 Services 1544 ANNEX C. OLD MODE OF CESoPSN ENCAPSULATION OVER L2TPV3 1546 Previous versions of this specification defined a CESOPSN PW 1547 encapsulation over L2TPv3 which differs from one described in Section 1548 4.3 and Diagram 2b. In these versions the RTP header, if used, precedes 1549 the CESoPSN control word. 1551 Existing implementations of the old encapsulation mode MUST be 1552 distinguished from the encapsulations conforming to this specification 1553 via the CESOPSN PW setup.