idnits 2.17.1 draft-ietf-pwe3-tdm-control-protocol-extensi-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4446], [RFC4447]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 20, 2008) is 5871 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Vainshtein (ECI Telecom) 3 Internet Draft Y(J) Stein (RAD Data Communications) 5 Intended Status: Proposed Standard 7 Creation Date: March 20, 2008 9 Expiration Date: September 2008 11 Control Protocol Extensions for Setup of TDM Pseudowires 12 in MPLS Networks 14 draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document defines extension to the PWE3 control protocol [RFC4447] 41 and PWE3 IANA allocations [RFC4446] required for setup of TDM 42 pseudowires in MPLS networks. 44 TABLE OF CONTENTS 46 1. Introduction......................................................2 47 2. PW FEC for Setup of TDM PWs.......................................3 48 3. Interface Parameters for TDM PWs..................................4 49 3.1. Overview......................................................4 50 3.2. CEP/TDM Payload Bytes.........................................4 51 3.3. CEP/TDM Bit-Rate (0x07).......................................5 52 3.4. Number of TDMoIP AAL1 cells per packet........................6 53 3.5. TDMoIP AAL1 mode..............................................6 54 3.6. TDMoIP AAL2 Options...........................................6 55 3.7. Fragmentation Indicator.......................................7 56 3.8. TDM Options...................................................7 57 4. Extending CESoPSN Basic NxDS0 Services with CE Application 58 Signaling............................................................9 59 5. LDP Status Codes.................................................10 60 6. Using the PW Status TLV..........................................10 61 7. IANA Considerations..............................................11 62 8. Security Considerations..........................................11 63 9. Acknowledgements.................................................11 64 10. Disclaimer of Validity..........................................12 65 11. Normative References............................................12 66 12. Informational References........................................12 67 13. Full Copyright Statement........................................13 68 14. Acknowledgement.................................................13 69 15. Authors' Addresses..............................................13 71 1. Introduction 73 This document defines extension to the PWE3 control protocol [RFC4447] 74 and PWE3 IANA allocations [RFC4446] required for setup of TDM 75 pseudowires in MPLS networks. 77 Structure-agnostic TDM pseudowires have been specified in [RFC4553] 78 and structure-aware ones in [RFC5086] and [RFC5087]. 80 [RFC4447] defines extensions to LDP [RFC5036] that are required to 81 exchange PW labels for PWs emulating various Layer 2 services 82 (Ethernet, FR, ATM, HDLC etc.). Setup of TDM PWs requires both 83 interpretation of the existing information elements of these extensions 84 and exchange of additional information. 86 Setup of TDM PWs using L2TPv3 will be defined in a separate document. 88 Status of attachment circuits of TDM PWs can be exchanged between the 89 terminating PEs using the PW Status mechanism defined in [RFC4447] 90 without any changes. However, usage of this mechanism is NOT 91 RECOMMENDED for TDM PWs, since indication of status of the TDM 92 attachment circuits is carried in-band in the data plane. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119. 98 2. PW FEC for Setup of TDM PWs 100 [RFC4447] uses LDP Label Mapping message [RFC5036] for advertising 101 the FEC-to-PW Label binding, and defines two types of PW FEC that can 102 be used for this purpose: 104 1. PWId FEC (FEC 128). This FEC contains: 105 a) PW type 106 b) Control bit (indicates presence of the control word) 107 c) Group ID 108 d) PW ID 109 e) Interface parameters 110 2. Generalized PW FEC (FEC 129). This FEC contains only: 111 a) PW type 112 b) Control bit 113 c) AGI, SAII and TAII that replace the PW ID 115 The Group ID and the Interface parameters are contained in separate 116 TLVs, called the PW Grouping TLV and the Interface Parameters TLV. 118 Either of these types of PW FEC MAY be used for setup of TDM PWs with 119 appropriate selection of PW types and interface parameters. 121 The PW Types for TDM PWs are allocated in [RFC4446] as follows: 123 o 0x0011 Structure-agnostic E1 over Packet [RFC4553] 124 o 0x0012 Structure-agnostic T1 (DS1) over Packet [RFC4553] 125 o 0x0013 Structure-agnostic E3 over Packet [RFC4553] 126 o 0x0014 Structure-agnostic T3 (DS3) over Packet [RFC4553] 127 o 0x0015 CESoPSN basic mode [RFC5086] 128 o 0x0016 TDMoIP AAL1 mode [RFC5087] 129 o 0x0017 CESoPSN TDM with CAS [RFC5086] 130 o 0x0018 TDMoIP AAL2 mode [RFC5087] 132 The two endpoints MUST agree on the PW type, as both directions of the 133 PW are required to be of the same type. 135 The Control bit MUST always be set for TDM PWs since all TDM PW 136 encapsulations always use a control word. 138 PW Type 0x0012 MUST also be used for setup of structure-agnostic TDM 139 PWs between a pair of J1 attachment circuits (see [RFC4805]). 141 3. Interface Parameters for TDM PWs 142 3.1. Overview 144 The interface parameters that are relevant for setup of the TDM PWs are 145 listed below. 147 ------------------------------------------------------------- 148 | Interface Parameter | Type | Length | Description | 149 |-----------------------|------------|--------|-------------| 150 | CEP/TDM Payload Bytes | 0x04 | 4 |Section 3.2 | 151 |-----------------------|------------|--------|-------------| 152 | CEP/TDM Bit-Rate | 0x07 | 6 |Section 3.3 | 153 |-----------------------|------------|--------|-------------| 154 | Number of TDMoIP AAL1 |TBA by IANA.| 4 |Section 3.4 | 155 | Cells per Packet |Suggested: | | | 156 | | 0x0E | | | 157 |-----------------------|-------=----|--------|-------------| 158 | TDMoIP AAL1 mode |TBA by IANA.| 4 |Section 3.5 | 159 | |Suggested: | | | 160 | | 0x10 | | | 161 |-----------------------|------------|--------|-------------| 162 | TDMoIP AAL2 Options |TBA by IANA | 8 or |Section 3.6 | 163 | |Suggested: | larger | | 164 | | 0x11 |see note| | 165 |-----------------------|------------|--------|-------------| 166 | Fragmentation | 0x09 | 4 |Section 3.7 | 167 | Indicator | | | | 168 |-----------------------|------------|--------|-------------| 169 | TDM Options | 0x0B | 4, 8, |Section 3.8 | 170 | | | or 12 | | 171 ------------------------------------------------------------- 173 If not explicitly indicated otherwise in the appropriate description, 174 the value of the interface parameter is interpreted as an unsigned 175 integer of the appropriate size (16 or 32 bits). 177 Note: The length of basic TDMoIP AAL2 Options interface parameter is 8 178 bytes, and when the optional CID mapping bases field is used there is 179 one additional byte for each trunk transported. Thus if 1 trunk is 180 being supported, this message occupies 9 bytes. Since there can be no 181 more than 248 CIDs in a given PW, this can never exceed 256 (this when 182 when each channel comes from a different trunk). 248 channels 183 translates to less than 9 E1s, and so for this case the length is no 184 more than 17 bytes. A single PE is not required to support more than 10 185 AAL2 PWs (i.e., up to 2480 individual channels, which is more than 186 carried by a fully populated STM1). Thus the memory required to store 187 all the AAL2 mapping information is typically between 80 and 170 bytes 188 per PE. 190 3.2. CEP/TDM Payload Bytes 192 This parameter is used for setup of all SAToP and CESoPSN PWs (i.e. PW 193 types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015 and 0x0017) and employs 194 the following semantics: 196 1. The two endpoints of a TDM PW MUST agree on the same value of 197 this parameter for the PW to be set up successfully. 198 2. Presence of this parameter in the PWId FEC or in the Interface 199 Parameters Field TLV is OPTIONAL. If this parameter is omitted, 200 default payload size defined for the corresponding service (see 201 [RFC4553], [RFC5086]) MUST be assumed 202 3. For structure-agnostic emulation, any value consistent with the 203 MTU of the underlying PSN MAY be specified 205 4. For CESoPSN PWs: 206 a) The specified value P MUST be an integer multiple of N, 207 where N is the number of timeslots in the attachment 208 circuit 209 b) For trunk-specific NxDS0 with CAS: 210 i) (P/N) MUST be an integer factor of the number of 211 frames per corresponding trunk multiframe (i.e. 16 212 for an E1 trunk and 24 for a T1 or J1 trunk) 213 ii) The size of the signaling sub-structure is not 214 accounted for in the specified value P. 215 5. This parameter MUST NOT be used for setup of TDMoIP PWs (i.e., 216 PWs with PW types 0x0016 and 0x0018). 218 3.3. CEP/TDM Bit-Rate (0x07) 220 This interface parameter represents the bit-rate of the TDM service in 221 multiples of the "basic" 64 Kbit/s rate. Its usage for all types of TDM 222 PWs assumes the following semantics: 224 1. This interface parameter MAY be omitted if the attachment circuit 225 bit-rate can be unambiguously derived from the PW Type (i.e. for 226 structure-agnostic emulation of E1, E3 and T3 circuits). If this 227 value is omitted for the structure-agnostic emulation of T1 PW 228 Type, the basic emulation mode MUST be assumed. 229 2. If present, only the following values MUST be specified for 230 structure-agnostic emulation (see [RFC4553]: 231 a) Structure-agnostic E1 emulation - 32 232 b) Structure-agnostic T1 emulation: 233 i) MUST be set to 24 in the basic emulation mode 234 ii) MUST be set to 25 for the "Octet-aligned T1" emulation mode 235 c) Structure-agnostic E3 emulation - 535 236 d) Structure-agnostic T3 emulation - 699 237 3. For all kinds of structure-aware emulation, this parameter MUST be 238 set to N where N is the number of DS0 channels in the corresponding 239 attachment circuit. 241 Note: The value 24 does not represent the actual bit-rate of the T1 or 242 J1 circuit (1,544 Mbit/s) in units of 64 kbit/s. The values mentioned 243 above are used for convenience. 245 Note: A 4-byte space is reserved for this parameter for compatibility 246 with [RFC4842]. 248 3.4. Number of TDMoIP AAL1 cells per packet 250 This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) 251 and specifies the number of 48-byte AAL1 PDUs per MPLS packet. Any 252 values consistent with the MTU of the underlying PSN MAY be specified. 253 If this parameter is not specified it defaults to 1 PDU per packet for 254 low bit-rates (CEP/TDM Bit-Rate less than or equal to 32), and to 5 for 255 high bit-rates (CEP/TDM Bit-Rate of 535 or 699). 257 3.5. TDMoIP AAL1 mode 259 This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) 260 and specifies the AAL1 mode. If this parameter is not present, the AAL1 261 mode defaults to "structured". When specified, the values have the 262 following significance: 263 0 - unstructured AAL1 264 2 - structured AAL1 265 3 - structured AAL1 with CAS. 266 The two endpoints MUST agree on the TDMoIP AAL1 mode. 268 3.6. TDMoIP AAL2 Options 270 This parameter MUST be present for TDMoIP AAL2 mode PWs (PW type 271 0x0018) and has the following format: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | 0x0F | Length | V | ENCODING | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Maximum Duration | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | CID mapping bases | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 The fields in this parameter are defined as follows: 285 V defines the VAD capabilities. Its values have the following 286 significance: 287 0 means that activity is only indicated by signaling 288 1 means that voice activity detection is employed 289 3 means this channel is always active. In particular, this channel 290 may be used for timing recovery. 292 Encoding specifies native signal processing performed on the payload. 293 When no native signal processing is performed (i.e. G.711 encoding) 294 this field MUST be zero. Other specific values that can be used in this 295 field are beyond the scope of this specification, but the two 296 directions MUST match for the PW setup to succeed. 298 Maximum Duration specifies the maximum time allowed for filling an AAL2 299 PDU, in units of 125 microseconds. For unencoded 64 kbps channels this 300 numerically equals the maximum number of bytes per PDU, and MUST be 301 less than 64. For other encoding parameters, larger values may be 302 attained. 304 CID mapping bases is an OPTIONAL parameter, its existence and length 305 determined by the length field. If the mapping of AAL2 CID values to 306 physical interface and time slot is statically configured, or if AAL2 307 switching [Q.2630.1] is employed, this parameter MUST NOT appear. When 308 it is present, and the channels belong to N physical interfaces (i.e. N 309 E1s or T1s), it MUST be N bytes in length. Each byte represents a 310 number to be subtracted from the CID to get the timeslot number for 311 each physical interface. For example, if the CID mapping bases 312 parameter consists of the bytes 20 and 60, this signifies that timeslot 313 1 of trunk 1 corresponds to CID 21 and timeslot 1 of trunk 2 is called 314 61. 316 3.7. Fragmentation Indicator 318 This interface parameter is specified in [RFC4446] and its usage is 319 explained in [RFC4623]. It MUST be omitted in the FEC of all TDM PWs 320 excluding trunk-specific NxDS0 services with CAS using the CESoPSN 321 encapsulation. In case of these services, it MUST be present in the PW 322 FEC if the payload size specified value P differs from Nx(number of 323 frames per trunk multiframe). 325 3.8. TDM Options 327 This is a new interface parameter. Its Interface Parameter ID (0x08) 328 has been assigned by IANA, and its format is shown in Fig. 1 below: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Parameter ID | Length |R|D|F|X|SP |CAS| RSVD-1 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |0| PT | RSVD-2 | FREQ | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | SSRC | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 1. Format of the TDM Options Interface Parameter 342 The fields shown in this diagram are used as follows: 344 Parameter ID Identifies the TDM PW Options interface parameter, 345 value TBA by IANA 346 Length 4, 8 or 12 (see below) 347 R The RTP Header Usage bit: if set, indicates that 348 the PW endpoint distributing this FEC expects to 349 receive RTP header in the encapsulation. RTP header 350 will be used only if both endpoints expect to 351 receive it. If this bit is cleared, Length MUST be 352 set to 4, otherwise it MUST be either 8 or 12 (see 353 below). If the peer PW end point cannot meet this 354 requirement, the Label Mapping message containing 355 the FEC in question MUST be rejected with the 356 appropriate status code (see Section 4 below). 357 D The Differential timestamping Mode bit: if set, 358 indicates that the PW endpoint distributing this 359 FEC expects the peer to use Differential 360 timestamping mode in the packets sent to it. If the 361 peer PW end point cannot meet this requirement, the 362 Label Mapping message containing the FEC in 363 question MUST be rejected with the appropriate 364 status code (see Section 4 below). 365 F, X Reserved for future extensions. MUST be cleared 366 when distributed and MUST be ignored upon reception 367 SP Encodes support for the CESoPSN signaling packets 368 (see [RFC5086]): 369 o '00' for PWs that do not use signaling 370 packets 371 o '01' for CESoPSN PWs carrying TDM data 372 packets and expecting CE application 373 signaling packets in a separate PW 374 o '10' for a PW carrying CE application 375 signaling packets with the data packets in a 376 separate PW 377 o '11' - for CESoPSN PWs carrying TDM data and 378 CE application signaling on the same PW 379 CAS MUST be cleared for all types of TDM PWs excluding 380 trunk-specific NxDS0 services with CAS. For these 381 services it encodes the trunk framing like 382 following: 383 o '01' - an E1 trunk 384 o '10' - a T1/ESF trunk 385 o '11' - a T1 SF trunk 386 RSVD-1 and RSVD-2 Reserved bits, MUST be set to 0 by the PW endpoint 387 distributing this FEC and MUST be ignored by the 388 receiver 389 PT Indicates the value of Payload Type in the RTP 390 header expected by the PW endpoint distributing 391 this FEC. Value 0 means that PT value check will 392 not be used for detecting malformed packets 393 FREQ Frequency of timestamping clock in units of 8 kHz 394 SSRC Indicates the value of SSRC ID in the RTP header 395 expected by the PW endpoint distributing this FEC. 396 Value 0 means that SSRC ID value check will not be 397 used for detecting misconnections. Alternatively, 398 Length can be set to 8 in this case. 400 Notes: 402 1. This interface parameter MAY be omitted in the following cases: 403 a) SAToP PWs that do not use RTP header [RFC4553] 404 b) Basic CESoPSN NxDS0 services without CE application 405 signaling [RFC5086] 406 c) TDMoIP AAL1 mode 0 or 2 PWs that do not use RTP 407 d) TDMoIP AAL2 PWs that do not relay CAS signaling and do 408 not use RTP. 409 2. This interface parameter MUST be present in the following cases: 410 a) All TDM PWs that use RTP header 411 b) CESoPSN PWs that carry basic NxDS0 services and use 412 CESoPSN signaling packets to carry CE application 413 signaling. This case is discussed in detail in Section 4 414 below 415 c) CESoPSN PWs that carry trunk-specific NxDS0 services with 416 CAS 417 d) TDMoIP AAL1 mode 1 PWs 418 e) TDMoIP AAL2 PWs that relay CAS signaling. 419 3. If RTP header and possibly the Differential timestamping mode 420 are used, the value of the Length field MUST be set to 8 or 12 421 in order to accommodate the Timestamping Clock Frequency and 422 SSRC fields 423 4. Usage or non-usage of the RTP header MUST match for the two 424 directions making up the TDM PW. However, it is possible to use 425 Differential timestamping mode in just one direction. 427 4. Extending CESoPSN Basic NxDS0 Services with CE Application Signaling 429 [RFC5086] defines that basic NxDS0 services can be extended to carry CE 430 application signaling (e.g., CAS) in special signaling packets carried 431 in a separate PW. 433 The following rules define setup of matching pairs of CESoPSN PWs using 434 the PW Id FEC and the extensions defined above: 436 1. The two PWs MUST: 437 a) Have the same PW Type 438 b) Use the same setup method (i.e. either both use the PWId 439 FEC, or both use the Generalized PW FEC) 440 c) Have the same values of all the Interface Parameters 441 listed in Section 3.1 above with the exception of the 442 code point in the SP field of the TDM Options parameter: 443 i) For the PW carrying TDM data packets the SP bits 444 MUST be set to '01' 445 ii) For the PW carrying the signaling packets, the SP 446 bits MUST set to '10' 447 2. If the PWId FEC has been used: 449 a) The value of PW ID for the CESoPSN PW carrying TDM data 450 packets MUST be even 451 b) The value of PW ID for the CESoPSN PW carrying CE 452 application signaling MUST be the next (odd) value after 453 the (even) PW ID of the CESoPSN PW carrying TDM data 454 packets 456 When using the Generalized PW FEC for setup of the two PWs, no specific 457 rules for matching the two FECs are defined. Implementation specific 458 mechanisms MAY be employed to verify the proper matching of the TDM 459 data PW with its associated CE signaling PW. 461 If one of the two associated PWs has been established and the other 462 failed to be established, or for any reason fails after having been 463 established, the established PW MUST be torn down. 465 5. LDP Status Codes 467 In addition to the status codes defined in sections 5.1 and 7.2 of 468 [RFC4447], the following status codes defined in [RFC4446] MUST be used 469 to indicate the reason of failure to establish a TDM PW: 471 1. Incompatible bit rate: 472 a) In the case of mismatch of T1 encapsulation modes (basic 473 vs. octet-aligned) 474 b) In case of mismatch in the number of timeslots for NxDS0 475 basic services or trunk-specific NxDS0 services with CAS 476 2. CEP/TDM misconfiguration: 477 a) In the case of mismatch in the desired usage of RTP 478 header 479 b) In the case of mismatch of the desired timestamping clock 480 frequency 481 c) In the case of mismatch of expected signaling packets 482 behavior for basic CESoPSN NxDS0 services extended to 483 carry CE application signaling in separate signaling 484 packets 485 d) In the case of trunk-specific NxDS0 services with CAS if 486 the framing types of the trunks are different 487 e) In the case of TDMoIP AAL1 PWs with different AAL1 modes 488 specified by the end points 489 3. The generic misconfiguration error MAY be used to indicate any 490 setup failure not covered above. 492 In cases 2a, 2b, 2c and 2e above, the user MAY reconfigure the end 493 points and attempt to setup the PW once again. 495 In the case 2d the failure is fatal. 497 Note that setting of the Control bit (see section 2 above) to zero MUST 498 result in an LDP status of "Illegal C-Bit". 500 6. Using the PW Status TLV 501 The TDM PW control word carries status indications for both attachment 502 circuits (L and M fields) and the PSN (R field) indication (see 503 [RFC4553], [RFC5086] and [RFC5087]). Similar functionality is available 504 via use of the PW Status TLV (see [RFC4447], Section 5.4.2). 505 If the latter mechanism is employed, the signaling PE sends its peer a 506 PW Status TLV for this PW, setting the appropriate bits (see [RFC4446], 507 Section 3.5): 509 o Pseudo Wire Not Forwarding 510 o Local Attachment Circuit (ingress) Receive Fault 511 o Local Attachment Circuit (egress) Transmit Fault 512 o Local PSN-facing PW (ingress) Receive Fault 513 o Local PSN-facing PW (egress) Transmit Fault. 515 As long as the TDM PW interworking function is operational, usage of 516 the Status TLV is NOT RECOMMENDED in order to avoid contention between 517 status indications reported by the data and control plane. However, if 518 the TDM PW interworking function (IWF) itself fails while the PWE3 519 control plane remains operational, a Status TLV with all of the above 520 bits set SHOULD be sent. 522 7. IANA Considerations 524 Most of the IANA assignments required by this draft are already listed 525 in [RFC4446]. Additional assignments are required for three Interface 526 Parameters Sub-TLV type values (see Section 3.1): 528 o Number of TDMoIP AAL1 cells per packet (suggested value - 0x0E) 529 o TDMoIP AAL1 mode (suggested value - 0x10) 530 o TDMoIP AAL2 Options (suggested value - 0x11). 532 8. Security Considerations 534 This draft does not have any additional impact on security of PWs above 535 that of basic LDP-based setup of PWs specified in [RFC4447]. 537 9. Acknowledgements 539 Sharon Galtzur has reviewed one of the previous versions of this 540 document. 541 Y(J)S would like to thank Barak Schlosser for helpful discussions. 543 Disclaimer of Validity 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed 547 to pertain to the implementation or use of the technology 548 described in this document or the extent to which any license 549 under such rights might or might not be available; nor does it 550 represent that it has made any independent effort to identify any 551 such rights. Information on the procedures with respect to rights 552 in RFC documents can be found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use 557 of such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository 559 at http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention 562 any copyrights, patents or patent applications, or other 563 proprietary rights that may cover technology that may be required 564 to implement this standard. Please address the information to the 565 IETF at ietf-ipr@ietf.org. 567 10. Normative References 569 [RFC5036] L. Andersson et al, LDP Specification, RFC 5036, IETF, 2007 571 [RFC4447] L. Martini et al, Pseudowire Setup and Maintenance using LDP, 572 RFC 4447, 2006 574 [RFC4446] L. Martini, IANA Allocations for Pseudo Wire Edge to Edge 575 Emulation (PWE3), RFC 4446, 2006 577 [RFC4623] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly, RFC 578 4623, 2006 580 [RFC4553] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over Packet 581 (SAToP), RFC 4553, 2006 583 11. Informational References 585 [RFC5086] A. Vainshtein et al, Structure-aware TDM Circuit Emulation 586 Service over Packet Switched Network (CESoPSN), RFC 5086, 2007 588 [RFC5087] Y(J) Stein et al, TDM over IP, RFC 5087 2007. 590 [Q.2630.1] ITU-T Recommendation Q.2630.1, December 1999, AAL type 2 591 signaling protocol - Capability set 1 593 [RFC4805] O. Nicklass, Definitions of Managed Objects for the DS1, J1, 594 E1, DS2, and E2 Interface Types, RFC 4805, 2007 596 [RFC4842] A. Malis et al, Synchronous Optical Network/Synchronous 597 Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP), RFC 598 4842, 2007 600 12. Full Copyright Statement 602 Copyright (C) The IETF Trust (2008). 604 This document is subject to the rights, licenses and restrictions 605 contained in BCP 78, and except as set forth therein, the authors 606 retain all their rights. 608 This document and the information contained herein are provided on an 609 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 610 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 611 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 612 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 613 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 614 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 616 13. Acknowledgement 618 Funding for the RFC Editor function is currently provided by the 619 Internet Society. 621 14. Authors' Addresses 623 Alexander ("Sasha") Vainshtein 624 ECI Telecom 625 30 ha-Sivim St., 626 PO Box 500 Petah-Tiqva, 49517 Israel 627 email: Alexander.Vainshtein@ecitele.com 629 Yaakov (Jonathan) Stein 630 RAD Data Communications 631 24 Raoul Wallenberg St., Bldg C 632 Tel Aviv 69719 633 ISRAEL 635 Phone: +972 3 645-5389 636 Email: yaakov_s@rad.com