idnits 2.17.1 draft-ieft-l2tpext-tdm-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. 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 ([PWE3-CESoPSN], [RFC4553]), 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 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 (February 2007) is 6273 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2TP TDM February 2007 3 Network Working Group A. Vainshtein 4 Internet Draft Axerra Networks 5 Document: draft-ieft-l2tpext-tdm-03.txt S. Galtzur 6 Rawflow 7 Intended Status: Proposed Standard 8 Expires: August 2007 February 2007 10 Layer Two Tunneling Protocol - Setup of TDM Pseudowires 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 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 Abstract 36 This document defines extensions to the Layer Two Tunneling Protocol 37 (L2TP) for support of structure-agnostic [RFC4553] and structure- 38 aware [PWE3-CESoPSN] pseudowires. 40 Conventions used in this document 42 In this document we refer to control plane as the packets that 43 contain control information (via AVP) and the mechanism that handle 44 these packets. 45 In this document we refer to the data plane as the packets that 46 contain transported user data. 48 L2TP TDM February 2007 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119 [RFC2119]. 54 Table of Contents 56 1. Introduction...................................................2 57 2. L2TP Extension.................................................2 58 2.1 TDM PW AVP (ICRQ, OCRQ)...................................3 59 2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)..........................4 60 2.3 Changes in the Control Connection AVPs.....................5 61 2.4 Changes in the Session Connection AVPs.....................5 62 3. Creation of the TDM Pseudowire Session.........................5 63 4. IANA Considerations............................................6 64 Security Considerations...........................................7 65 Copyright notice..................................................7 66 Normative references..............................................8 67 Informative references............................................8 68 Authors' Addresses................................................8 70 1. Introduction 72 This document defines extensions to the Layer Two Tunneling Protocol 73 (L2TP) for support of structure-agnostic [RFC4553] and structure- 74 aware [PWE3-CESoPSN] pseudowires. Setup of structure-aware 75 pseudowires using encapsulations described in [PWE3-TDMoIP] has been 76 left for further study. 78 2. L2TP Extension 80 The L2TP Control Connection is responsible for 3 main operations: 81 1. Establishment and validation of session. 82 2. Ending (tearing down) of session. 83 3. Transferring of End Point status. 85 Tearing down of session is identical to [RFC3931]. 87 [PWE3-CESoPSN] and [RFC4553] describe how to transfer the End Point 88 status via the data plane. This is therefore RECOMMENDED to not use 89 the Set-Link-Info (SLI) described in [RFC3931]. 91 The next sections describe the extensions to the L2TP for 92 establishment and validation of TDM pseudowire sessions. 94 There are 2 new AVPs for the Session Connection Messages. One AVP 95 describe the TDM pseudowire attributes. The second AVP describe the 96 RTP attributes for this TDM pseudowire. 98 L2TP TDM February 2007 100 2.1 TDM PW AVP (ICRQ, OCRQ) 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |M|H| rsvd | Length | Vendor Id (IETF) | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Attribute Type (AVP-TBA-1) | Reserved |CAS| 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Bit Rate | CEP/TDM Payload Bytes | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 113 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 114 12. 116 Bit Rate is defined in [RFC4446]. Its usage for all types of TDM PWs 117 implies the following semantics: 118 1) Only the following values MUST be specified for structure-agnostic 119 emulation (see [RFC4553]): 120 a) Structure-agnostic E1 emulation - 32 121 b) Structure-agnostic T1 emulation: 122 i) MUST be set to 24 for the basic mode 123 ii) MUST be set to 25 for the "Octet-aligned T1" mode 124 c) Structure-agnostic E3 emulation - 535 125 d) Structure-agnostic T3 emulation - 699 126 2) For all kinds of structure-aware emulation, this parameter MUST be 127 set to the number of DS0 channels in the corresponding attachment 128 circuit. 130 Note: for structure-agnostic T1 emulation the value 24 does not 131 indicate the exact bit rate, and is used for convenience only. 133 CEP/TDM Payload Bytes has been defined in [RFC4446]. It can be used 134 for setup of all types of TDM PWs without any changes in its encoding 135 (see [RFC4446]) with the following semantics: 137 1) For Structure-agnostic emulation any value of the payload bytes can 138 be specified. 139 2) For CESoPSN PWs: 140 a) The specified value MUST be an integer multiple of number of 141 DS0 channels in the corresponding attachment circuit. 142 b) For trunk-specific NxDS0 with CAS, (Payload Bytes/number of DS0 143 channels) must be an integer factor of the number of frames per 144 corresponding trunk multiframe. 146 The Reserved bits are reserved. They MUST be set to 0 on transmission 147 and MUST be ignored on reception. 149 L2TP TDM February 2007 151 CAS bits define the trunk type for trunk-specific CESoPSN services 152 with CAS. These bits: 153 1) MUST be set to 0 for all pseudowire types excluding trunk-specific 154 CESoPSN with CAS 155 2) For trunk-specific CESoPSN with CAS these bits bust be set to: 156 a) '01' in the case of an E1 trunk 157 b) '10' in the case of a T1/ESF trunk 158 c) '11' in the case of a T1/SF trunk. 160 2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP) 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |M|H| rsvd | Length | Vendor Id (IETF) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Attribute Type (AVP-TBA-2) |D| PT |C| Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Reserved | Timestamp Clock Frequency | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | SSRC | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 This AVP MUST appear if and only if the RTP header is used in the TDM 175 pseudowire encapsulation. This AVP MAY be hidden (the H bit MAY be 0 176 or 1). The M bit for this AVP SHOULD be set to 0. The Length 177 (before hiding) of this AVP is 16. 179 The D bit indicates the timestamping mode (absolute or differential) 180 in the RTP header. These modes are described in, e.g., in [RFC4553], 181 Section 4.3.2. If the D bit is set to 1 then the differential 182 timestamping mode is used, otherwise absolute timestamping mode is 183 used. Differential mode can be used only if both sides use RTP and 184 use differential time stamping. 186 The C bit indicates the ordering of the RTP header and the control 187 word as following: 189 o If the C bit is set to 1 the RTP header appears after the control 190 word in the data channel of the TDM pseudowire. This mode is 191 described as SAToP/CESoPSN encapsulation over IPv4/IPv6 PSN with 192 L2TPv3 demultiplexing in [RFC4553] and [PWE3-CESoPSN] respectively. 193 o If the C bit is set to 0 the RTP header appears before the control 194 word. This mode described as the old mode of the SAToP/CESoPSN 195 encapsulation over L2TPv3 in [RFC4553], Appendix A, and [PWE3- 196 CESoPSN], Annex C, respectively. 198 L2TP TDM February 2007 200 PT is the payload type expected in the RTP header. Value of zero 201 indicates that the payload type is ignored and will not be used to 202 detect malformed packets. 203 Timestamp Clock Frequency is the clock frequency used for the time 204 stamping in 8 KHz. 206 SSRC indicates the expected value of SSRC ID in the RTP header. A 207 zero in this field means that SSRC ID will not be used for detecting 208 misconnections. Since L2TP provides an alternative security mechanism 209 via the cookies, if the cookie length is larger then zero the SSRC 210 SHOULD be zero. 212 2.3 Changes in the Control Connection AVPs 214 Control Connection that support TDM MUST add the appropriate PW Type 215 value to the list in the Pseudowire Capabilities List AVP. The exact 216 value is TBA by IANA and is listed in the next section. 218 2.4 Changes in the Session Connection AVPs 220 PW Type AVP should be set to one of the following values: 221 1. Structure-agnostic emulation [RFC4553] of: 222 a. E1 circuits - TBA-SAToP-E1 by IANA. The value 0x0011 is 223 suggested for alignment with [RFC4446] 224 b. T1 circuits - TBA-SAToP-T1 by IANA. The value 0x0012 is 225 suggested for alignment with [RFC4446] 226 c. E3 circuits - TBA-SAToP-E3 by IANA. The value 0x0013 is 227 suggested for alignment with [RFC4446] 228 d. T3 circuits - TBA-SAToP-T3 by IANA. The value 0x0014 is 229 suggested for alignment with [RFC4446] 230 2. Structure-aware emulation [PWE3-CESoPSN] of: 231 a. CESoPSN basic mode - TBA-CESoPSN-Basic by IANA. The value 232 0x0015 is suggested for alignment with [RFC4446] 233 b. Trunk-specific CESoPSN service with CAS - TBA-CESoPSN-CAS by 234 IANA. The value 0x0017 is suggested for alignment with 235 [RFC4446]. 237 TDM pseudowires use their own control word. Therefore the L2- 238 Specific Sublayer AVP MUST either be omitted or set to zero. 240 TDM pseudowires use their own sequencing. Therefore the Data 241 Sequencing AVP MUST either be omitted or set to zero. 243 3. Creation of the TDM Pseudowire Session 245 When LCCE wants to open a Session for TDM PW it MUST include the TDM 246 PW AVP (in any case) and the RTP AVP (if RTP and only if the RTP 247 header is used) in the ICRQ or OCRQ message. The LCCE peer must 248 validate the TDM PW AVP and make sure it can meet the requirements 249 L2TP TDM February 2007 251 derived from the RTP AVP (if it exist). If the peer agrees with the 252 TDM AVP it will send an appropriate ICRP or OCRP message with the 253 matching RTP AVP (if needed). The Initiator need to validate that it 254 can supply the requirements derived from the received RTP AVP. 256 The two peers MUST agree on the values in the TDM PW AVP: 258 1. Bit Rate values MUST be equal on both sides. If they are 259 different, the connection will be rejected with return code RC- 260 TBD-1 and error code EC-TBD-1. 261 2. In the case of trunk-specific CESoPSN with CAS, the trunk type (as 262 encoded in the CAS bits of the TDM AVP) MUST be the same for the 263 two sides. Otherwise the connection will be rejected with return 264 code RC-TBD-1 and error code EC-TBD-2. 265 3. If one side does not support the payload bytes value proposed by 266 the other one, the connection will be rejected with return code 267 RC-TBD-1 and error code EC-TBD-3. 268 4. If one side cannot send RTP header requested by the other side, 269 the connection will be rejected with return code RC-TBD-1 and 270 error code EC-TBD-4. 271 5. If one side can send RTP header but not with the requested 272 timestamp clock frequency, the connection will be rejected with 273 return code RC-TBD-1 and error code EC-TBD-5. 275 4. IANA Considerations 277 This draft requires assignment of the following values by IANA: 279 PW types listed in Section 2.1 above. It is RECOMMENDED to use the 280 same values as defined in [RFC4446]. 282 New attribute value pair IDs: 284 1. AVP-TBD-1 - TDM Pseudowire AVP 285 2. AVP-TBD-2 - RTP AVP 287 New return codes and error codes: 289 1. RC-TBD-1 - return code to indicate connection refused because of 290 TDM PW parameters. The exact error code is as follows. 291 2. EC-TBD-1 - indicate Bit Rate values disagree. 292 3. EC-TBD-2 - indicate different trunk types in the case of trunk- 293 specific CESoPSN with CAS 294 4. EC-TBD-3 - requested payload size too big or too small. 295 5. EC-TBD-4 - RTP header cannot be generated. 296 6. EC-TBD-5 - requested timestamp clock frequency cannot be 297 generated. 299 L2TP TDM February 2007 301 Security Considerations 303 There are no additional security considerations on top of the ones 304 discussed in [RFC3931] 306 Copyright notice 308 Copyright (C) The IETF Trust (2007). 310 This document is subject to the rights, licenses and restrictions 311 contained in BCP 78, and except as set forth therein, the authors 312 retain all their rights. 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 317 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 318 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 319 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 IPR Validity Disclaimer 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at 344 ietf-ipr@ietf.org. 346 L2TP TDM February 2007 348 Normative references 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997 353 [RFC3931] J. Lau, M. Townsley, I. Goyret, Layer Two Tunneling 354 Protocol - Version 3 (L2TPv3), March 2005 356 Informative references 358 [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit 359 Emulation Service over Packet Switched Network 360 (CESoPSN), Work in progress, May 2006, draft-ietf- 361 pwe3-cesopsn-07.txt 363 [RFC4553] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over 364 Packet (SAToP), RFC 4553, June 2006 366 [PWE3-TDMoIP] Y. Stein et al, TDM over IP, Work in progress, draft- 367 ietf-pwe3-tdmoip-06.txt, December 2006. 369 [RFC4446] L. Martini, M. Townsley, IANA Allocations for pseudo 370 Wire Edge to Edge Emulation (PWE3), RFC 4446, 371 April 2006 373 Authors' Addresses 375 Sharon Galtzur 376 Rawflow Inc. 377 The Old Pump House, 19 Hooper St., 378 London E1 8BU, 379 UK 380 Email: sharon@rawflow.com 382 Alexander Vainshtein, 383 Axerra Networks, 384 24 Raoul Wallenberg St., 385 Tel Aviv, Israel 386 Email: sasha@axerra.com