idnits 2.17.1 draft-ietf-l2tpext-tdm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 114 has weird spacing: '...Service over ...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 14, 2009) is 5484 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) ** Downref: Normative reference to an Informational RFC: RFC 5086 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Vainshtein 2 Internet Draft ECI Telecom 3 Document: draft-ietf-l2tpext-tdm-07.txt S. Galtzur 4 Rebellion 6 Creation Date: April 14, 2009 7 Intended Status: Proposed Standard 8 Expires: October 2009 10 Layer Two Tunneling Protocol version 3 - Setup of Time-Division 11 Multiplexing (TDM) Pseudowires 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 14, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Abstract 61 This document defines extensions to the Layer Two Tunneling Protocol 62 version 3 (L2TPv3) for support of structure-agnostic and structure- 63 aware (CESoPSN style) Time-Division Multiplexing (TDM) pseudowires. 64 Support of structure-aware (TDMoIP style) pseudowires over L2TPv3 is 65 left for further study. 67 Legal 69 This documents and the information contained therein are provided on 70 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 71 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 72 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 73 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 74 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 75 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 76 FOR A PARTICULAR PURPOSE. 78 Conventions used in this document 80 In this document we refer to control plane as the packets that 81 contain control information (via Attribute-Value pairs (AVP)) and the 82 mechanism that handles these packets. 83 In this document we refer to the data plane as the packets that 84 contain transported user data. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC-2119 [RFC2119]. 90 Table of Contents 92 1. Introduction...................................................3 93 2. L2TPv3 Extension...............................................3 94 2.1 TDM PW Attribute-Value Pair (AVP)(ICRQ, OCRQ)..............4 95 2.2 RTP Attribute-Value Pair AVP (ICRQ, OCRQ, ICRP, OCRP).....6 96 2.3 Changes in the Control Connection AVPs.....................7 97 2.4 Changes in the Session Connection AVPs.....................7 98 3. Creation of the TDM Pseudowire Session.........................7 99 4. IANA Considerations............................................8 100 5. Congestion Control.............................................9 101 6. Security Considerations........................................9 102 7. Acknowledgements...............................................9 103 Normative references..............................................9 104 Informative references...........................................10 105 Authors' Addresses...............................................10 107 1. Introduction 109 This document defines extensions to the Layer Two Tunneling Protocol 110 Version 3(L2TPv3) for support of structure-agnostic [RFC4553] and 111 structure-aware (CESoPSN style, see [RFC5086]) Time-Division 112 Multiplexing (TDM) pseudowires. Structure-agnostic encapsulation of 113 TDM bit-streams over L2TPv3 is described in [RFC4553], Figure 2b, and 114 Circuit Emulation Service over packet-Switched Networks (CESoPSN) 115 structure-aware encapsulation - in [RFC5086], Figures 1c (TDM data 116 packets) and 4a (CE application signaling packets). However, the 117 order of the CESoPSN Control Word (CW) and RTP header (if it is used) 118 MUST match between the TDM data and CE signaling packets. 120 Setup of structure-aware TDM pseudowires using encapsulations 121 described in [RFC5087] has been left for further study. 123 Setup and maintenance of TDM PWs in MPLS networks using LDP is 124 described in [RFC5287]. 126 2. L2TPv3 Extension 128 The L2TPv3 Control Connection is responsible for 3 main operations: 129 1. Establishment and validation of a pseudowire (PW) session. 130 2. Ending (tearing down) of a pseudowire session. 131 3. Transferring of End Point status. 133 Tearing down of session for a TDM pseudowire performed as described 134 in [RFC3931]. 136 [RFC5086] and [RFC4553] describe how to transfer the Attachment 137 Circuit (AC) status via the data plane. Therefore the Set-Link-Info 138 (SLI) message described in [RFC3931] SHOULD NOT be used for conveying 139 this status for the PWs in question. 141 [RFC3931] specifies that the Circuit Status Attribute-Value Pair 142 (AVP) MUST be present in the ICRQ/ICRP messages. It also specifies 143 that the N bit in this AVP should be set during the PW setup even if 144 the specific AC does not provide any way to convey the "new AC" 145 indication. Accordingly, the Circuit Status AVP for the PWs in 146 question, when used in the ICRQ/ICRP messages, MUST always have both 147 N and A bits set. 149 The next sections describe the extensions to L2TPv3 for establishment 150 and validation of TDM pseudowire sessions. 152 There are two new AVPs for the Session Management messages. One AVP 153 describes the TDM pseudowire attributes. The second AVP describes the 154 RTP attributes for this TDM pseudowire. 156 2.1 TDM PW Attribute-Value Pair (AVP)(ICRQ, OCRQ) 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |M|H| rsvd | Length | Vendor Id (IETF) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Attribute Type (AVP-TBA-1) | Reserved |SP |CAS| 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Bit Rate | Payload Bytes | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 169 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 170 12. 172 The Bit Rate field contains the value that represents the bit rate of 173 the local AC in the units of 64 Kbit/s encoded as an unsigned 16-bit 174 integer. Its usage for all types of TDM PWs employs the following 175 semantics: 176 1) Only the following values MUST be specified for structure- 177 agnostic emulation (see [RFC4553]): 178 a) Structure-agnostic E1 emulation - 32 179 b) Structure-agnostic T1 emulation: 180 i) MUST be set to 24 for the basic mode 181 ii) MUST be set to 25 for the "Octet-aligned T1" 182 mode 183 c) Structure-agnostic E3 emulation - 535 184 d) Structure-agnostic T3 emulation - 699 185 2) For CESoPSN PWs this parameter MUST be set to the number of 186 DS0 channels in the corresponding attachment circuit. 188 Note: For structure-agnostic T1 emulation, the values 24 and 25 do 189 not reflect the exact bit rate, and are used for convenience only. 191 Note: The semantics of the Bit Rate field defined above are 192 consistent with those of the Bit Rate Interface Attribute as defined 193 in [RFC5287]. 195 The Payload Bytes field contains the value representing the number of 196 the TDM Payload bytes in the PW packet and is used with the following 197 semantics: 199 1) For structure-agnostic emulation any value of the payload 200 bytes can be specified. 201 2) For CESoPSN PWs: 202 a) The specified value MUST be an integer multiple of the 203 number of DS0 channels in the corresponding attachment 204 circuit. 205 b) In addition to that, for trunk-specific NxDS0 with CAS, 206 the number of the trunk frames per multiframe fragment 207 (value resulting from the Payload Bytes divided by the 208 number of DS0 channels) MUST be an integer divisor of 209 the number of frames per corresponding trunk 210 multiframe. 212 The Reserved bits MUST be set to 0 on transmission and MUST be 213 ignored on reception. 215 The SP bits define support for the CESoPSN application signaling 216 packets (see [RFC5086]) and MUST be used as following: 217 1) Set to '01' for the CESoPSN PWs carrying TDM data packets and 218 expecting CE application signaling packets in a separate PW 219 2) Set to '10' for a PW carrying CE application signaling packets 220 with the data packets in a separate PW 221 3) Set to '11' for e CESoPSN PW carrying both TDM data and 222 signaling packets 223 4) Set to '00' for SAToP PWs and for CESoPSN PWs not using 224 separate signaling packets. 226 The CAS bits define the trunk type for trunk-specific CESoPSN 227 services with CAS. These bits: 228 1) For trunk-specific CESoPSN with CAS these bits MUST be set to: 229 a) '01' in the case of an E1 trunk 230 b) '10' in the case of a T1/ESF trunk 231 c) '11' in the case of a T1/SF trunk. 232 2) MUST be set to '00' for all the other TDM pseudowire types. 234 2.2 RTP Attribute-Value Pair AVP (ICRQ, OCRQ, ICRP, OCRP) 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |M|H| rsvd | Length | Vendor Id (IETF) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Attribute Type (AVP-TBA-2) |D| PT |C| Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Reserved | Timestamp Clock Frequency | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | SSRC | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Presence of this AVP indicates that the RTP header is used in the TDM 249 pseudowire encapsulation. Use or non-use of the RTP header MUST match 250 for the two directions of a TDM PW. This AVP MAY be hidden (the H bit 251 MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The 252 Length (before hiding) of this AVP is 16. 254 The D bit indicates the timestamping mode (absolute or differential) 255 in the RTP header. These modes are described in, e.g., in [RFC4553], 256 Section 4.3.2. If the D bit is set to 1 then the Differential 257 timestamping mode is used, otherwise the Absolute timestamping mode 258 is used. Timestamping modes can be used independently for the two 259 directions of a TDM PW. 261 The C bit indicates the ordering of the RTP header and the control 262 word as following: 264 o If the C bit is set to 1 the RTP header appears after the 265 control word in the data channel of the TDM pseudowire. This 266 mode is described as SAToP/CESoPSN encapsulation over 267 IPv4/IPv6 PSN with L2TPv3 demultiplexing in [RFC4553] and 268 [RFC5086] respectively. 269 o If the C bit is set to 0 the RTP header appears before the 270 control word. This mode described as the old mode of the 271 SAToP/CESoPSN encapsulation over L2TPv3 in [RFC4553], Appendix 272 A, and [RFC5086], Annex C, respectively. 274 PT is the payload type expected in the RTP header. A value of zero 275 indicates that the receiver shall not check payload type to detect 276 malformed packets. 278 Timestamp Clock Frequency is the clock frequency used for the time 279 stamping in units of 8 KHz. 281 SSRC indicates the expected value of SSRC ID in the RTP header. A 282 zero in this field means that SSRC ID will not be used for detecting 283 misconnections. Since L2TP provides an alternative security mechanism 284 using cookies, if the cookie length is larger than zero the SSRC 285 SHOULD be zero. 287 2.3 Changes in the Control Connection AVPs 289 Control Connections that support TDM PWs MUST add the appropriate PW 290 Type value(s) to the list in the Pseudowire Capabilities List AVP. 291 The valid values are listed in the next section. 293 2.4 Changes in the Session Connection AVPs 295 PW Type AVP should be set to one of the following values: 296 1. Structure-agnostic emulation [RFC4553] of: 297 a. E1 circuits - TBA-SAToP-E1 by IANA 298 b. T1 circuits - TBA-SAToP-T1 by IANA 299 c. E3 circuits - TBA-SAToP-E3 by IANA 300 d. T3 circuits - TBA-SAToP-T3 by IANA 301 2. Structure-aware emulation [RFC5086] of: 302 a. CESoPSN basic mode - TBA-CESoPSN-Basic by IANA 303 b. Trunk-specific CESoPSN service with CAS - TBA-CESoPSN- 304 CAS by IANA 306 TDM pseudowires use their own control word. Therefore the L2- 307 Specific Sublayer AVP MUST either be omitted or set to zero. 309 TDM pseudowires use their own sequencing. Therefore the Data 310 Sequencing AVP MUST either be omitted or set to zero. 312 Note: The Control Word (CW) used in the SAToP and CESoPSN 313 encapsulations over L2TPv3 effectively represents a dedicated L2- 314 Specific Sub-layer. 316 3. Creation of the TDM Pseudowire Session 318 When LCCE wants to open a Session for TDM PW it MUST include the TDM 319 PW AVP (in any case) and the RTP AVP (if and only if the RTP header 320 is used) in the ICRQ or OCRQ message. The LCCE peer must validate 321 the TDM PW AVP and make sure it can meet the requirements derived 322 from the RTP AVP (if it exists). If the peer agrees with the TDM AVP 323 it will send an appropriate ICRP or OCRP message with the matching 324 RTP AVP (if needed). The Initiator need to validate that it can 325 supply the requirements derived from the received RTP AVP. 327 The two peers MUST agree on the values in the TDM PW AVP: 329 1. Bit Rate values MUST be equal on both sides. If they are 330 different, the connection will be rejected with return code 331 RC-TBD-1 and error code EC-TBD-1. 332 2. In the case of trunk-specific CESoPSN with CAS, the trunk 333 type (as encoded in the CAS bits of the TDM AVP) MUST be the 334 same for the two sides. Otherwise the connection will be 335 rejected with return code RC-TBD-1 and error code EC-TBD-2. 336 3. If one side does not support the payload bytes value proposed 337 by the other one, the connection will be rejected with return 338 code RC-TBD-1 and error code EC-TBD-3. 339 4. If one side cannot send RTP header as requested by the other 340 side, the connection will be rejected with return code RC- 341 TBD-1 and error code EC-TBD-4. 342 5. If one side can send RTP header but not with the requested 343 timestamp clock frequency, the connection will be rejected 344 with return code RC-TBD-1 and error code EC-TBD-5. 346 If CE signaling for a CESoPSN basic PW is transported in a separate PW 347 instance, then the two PW instances: 349 1. MUST use the same PW type 350 2. MUST use the same values in all the fields of the TDM AVP 351 excluding the SP field which must be set to '01' for the TDM 352 data PW and to '10' for the PW carrying CE application 353 signaling 354 3. MUST both use or not use RTP header (and accordingly, 355 include or not include the RTP AVP). 357 4. IANA Considerations 359 This draft requires assignment of the following values by IANA: 361 New L2TPv3 Pseudowire Types: 363 0x0011 (TBA-SAToP-E1) - Structure-agnostic E1 circuit 364 0x0012 (TBA-SAToP-T1) - Structure-agnostic T1 (DS1) circuit 365 0x0013 (TBA-SAToP-E3) - Structure-agnostic E3 circuit 366 0x0014 (TBA-SAToP-T3) - Structure-agnostic T3 (DS3) circuit 367 0x0015 (TBA-CESoPSN-Basic) - CESoPSN basic mode 368 0x0017 (TBA-CESoPSN-CAS) - CESoPSN TDM with CAS 370 Note that the values listed are suggested to match with the values 371 defined in [RFC4446] for the MPLS Pseudowire Types. 373 New attribute value pair IDs: 375 1. AVP-TBD-1 - TDM Pseudowire AVP 376 2. AVP-TBD-2 - RTP AVP 378 New return codes for the CDN message: 380 1. RC-TBD-1 - return code to indicate connection refused 381 because of TDM PW parameters. The error code indicates the 382 problem. 384 TDM PW Specific error codes, to be used with the RC-TDB-1 return code 385 For the CDN message: 387 This is a new registry for IANA to maintain within the Result Code 388 AVP (Attribute Type 1) Values. Additional values may be assigned by 389 Expert Review [RFC5226]. 391 0. 0 - Reserved 392 1. EC-TBD-1 - Bit Rate values disagree. 393 2. EC-TBD-2 - Different trunk types in the case of trunk- 394 specific CESoPSN with CAS 395 3. EC-TBD-3 - Requested payload size too big or too small. 396 4. EC-TBD-4 - RTP header cannot be generated. 397 5. EC-TBD-5 - Requested timestamp clock frequency cannot be 398 generated 400 5. Congestion Control 402 The congestion considerations from [RFC4553] and [RFC5086] apply 403 respectively to the structure-agnostic and CESoPSN modes of this 404 specification. 406 6. Security Considerations 408 This document specifies only the L2TPv3-based control plane for setup 409 of TDM PWs. Within this scope, there are no additional security 410 considerations on top of those discussed in [RFC3931]. 412 Common data plane security considerations for the TDM PWs have been 413 discussed in some detail in both [RFC4553] and [RFC5086]. On top of 414 these, the L2TPv3-based data plane provides additional security 415 mechanisms based on usage of cookies. 417 7. Acknowledgements 418 The authors want to thank Carlos Pignataro, Ignacio Goyret and Yaakov 419 Stein for careful review and useful suggestions. 421 Normative references 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997 426 [RFC3931] J. Lau, M. Townsley, I. Goyret, Layer Two Tunneling 427 Protocol - Version 3 (L2TPv3), March 2005 429 [RFC5086] A. Vainshtein et al, Structure-aware TDM Circuit 430 Emulation Service over Packet Switched Network 431 (CESoPSN), RFC 5086, December 2007 433 [RFC4553] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over 434 Packet (SAToP), RFC 4553, June 2006 436 Informative references 438 [RFC5087] Y. Stein et al, TDM over IP, RFC 5087, December 2007. 440 [RFC4446] L. Martini, M. Townsley, IANA Allocations for Pseudo 441 Wire Edge to Edge Emulation (PWE3), RFC 4446, 442 April 2006 444 [RFC5287] A. Vainshtein, Y. Stein, Control Protocol Extensions 445 for Setup of TDM Pseudowires in MPLS Networks, RFC 5287, 446 August 2008 448 [RFC5226] T. Narten, H. Alvestrand, Guidelines for Writing an IANA 449 Considerations Section in RFCs, RFC 5226, May 2008 451 Authors' Addresses 453 Sharon Galtzur 454 Rebellion Inc. 455 29 The Chilterns, Gloucester Green, 456 Oxford, OX1 2DF, UK 457 Email: sharon.galtzur@rebellion.co.uk 459 Alexander Vainshtein, 460 ECI Telecom, 461 30 ha-Sivim St. PO Box 500, 462 Petah-Tiqva 49517, Israel 463 Email: Alexander.Vainshtein@ecitele.com