idnits 2.17.1 draft-galtzur-l2tpext-tdm-01.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 265. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([PWE3-CESoPSN], [PWE3-TDMoIP], [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 == Line 218 has weird spacing: '...tted or set t...' == Line 221 has weird spacing: '...tted or set t...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The two peers MUST agree on the values in the TDM PW AVP: 1. Bit Rate MUST be equal on both sides. 2. The Flavor bit MUST be equal on both sides 3. The Payload Bytes and the R bit MAY NOT be the same. -- 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 (October 2004) is 7130 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: 'ICRQ' is mentioned on line 159, but not defined == Missing Reference: 'OCRQ' is mentioned on line 159, but not defined == Missing Reference: 'IETF' is mentioned on line 164, but not defined == Missing Reference: 'TBD' is mentioned on line 166, but not defined == Missing Reference: 'PWE3-SONET' is mentioned on line 131, but not defined == Missing Reference: 'ICRP' is mentioned on line 159, but not defined == Missing Reference: 'OCRP' is mentioned on line 159, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-cesopsn-01 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-cesopsn (ref. 'PWE3-CESoPSN') == Outdated reference: A later version (-05) exists of draft-ietf-pwe3-satop-01 == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-tdmoip-01 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-tdmoip (ref. 'PWE3-TDMoIP') == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-07 Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft S. Galtzur 3 Document: draft-galtzur-l2tpext-tdm-01.txt Axerra Networks 4 Expires: April 2005 October 2004 6 Layer Two Tunneling Protocol - Setup of TDM Pseudowires 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC-2026 [RFC2026]. 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 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document defines extensions to the Layer Two Tunneling Protocol 36 (L2TP) for support of structure-agnostic [PWE3-SATOP] and structure- 37 aware [PWE3-CESoPSN], [PWE3-TDMoIP] pseudowires. 39 Conventions used in this document 41 In this document we refer to control plane as the packets that 42 contain control information (via AVP) and the mechanism that handle 43 these packets. 44 In this document we refer to the data plane as the packets that 45 contain transported user data. 47 L2TP TDM October 2004 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119 [RFC2119]. 53 Table of Contents 55 1. Introduction...................................................2 56 2. L2TP Extension.................................................2 57 2.1 TDM PW AVP [ICRQ, OCRQ]...................................3 58 2.2 RTP AVP [ICRQ, OCRQ, ICRP, OCRP]..........................4 59 2.3 Changes in the Control Connection AVPs.....................5 60 2.4 Changes in the Session Connection AVPs.....................5 61 3. Creation of the TDM Pseudowire Session.........................5 62 4. IANA Considerations............................................6 63 Security Considerations...........................................6 64 References........................................................6 65 Acknowledgments...................................................7 66 Author's Addresses................................................7 68 1. Introduction 70 This document defines extensions to the Layer Two Tunneling Protocol 71 (L2TP) for support of structure-agnostic [PWE3-SATOP] and structure- 72 aware [PWE3-CESoPSN], [PWE3-TDMoIP] pseudowires. 74 2. L2TP Extension 76 The L2TP Control Connection is responsible for 3 main operations: 77 1. Establishment and validation of session. 78 2. Ending (tearing down) of session. 79 3. Transferring of End Point status. 81 Tearing down of session is identical to [L2TP]. 83 [PWE3-CESoPSN] and [PWE3-SATOP] describe how to transfer the END 84 Point status via the Data Plane. This is therefore RECOMMENDED to not 85 use the Set-Link-Info (SLI) described in [L2TP]. 87 The next sections describe the extensions to the L2TP for 88 establishment and validation of TDM Pseudowire sessions. 90 There are 2 new AVPs for the Session Connection Messages. One AVP 91 describe the TDM Pseudowire attributes. The second AVP describe the 92 RTP attributes for this TDM Pseudowire. 94 L2TP TDM October 2004 96 2.1 TDM PW AVP [ICRQ, OCRQ] 98 0 1 2 3 99 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 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 |M|H| rsvd | Length | Vendor Id [IETF] | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Attribute Type [TBD] |R|T|F| Reserved | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Bit Rate | Payload Bytes | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 109 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 110 12. 112 Bit Rate is defined in [PWE3-IANA]. Its usage for all types of TDM 113 PWs assumes the following semantics: 114 1. This interface parameter MAY be omitted, if the attachment circuit 115 bit-rate is unambiguously derived from the PW Type. 116 2. Only the following values MUST be specified for structure-agnostic 117 emulation (see [PWE3-SATOP]: 118 a. Structure-agnostic E1 emulation - 32 119 b. Structure-agnostic T1 emulation: 120 1. MUST be set to 24 for the basic emulation mode 121 2. MUST be set to 25 for the "Octet-aligned T1" emulation mode 122 c. Structure-agnostic E3 emulation - 535 123 d. Structure-agnostic T3 emulation - 699 124 3. For all kinds of structure-aware emulation, this parameter MUST be 125 set to the number of DS0 channels in the corresponding attachment 126 circuit. 128 Note: for Structure-agnostic T1 emulation the value 24 does not 129 indicate the exact bit rate, and is used for convenience only. 131 Payload Bytes has been initially defined for CEP [PWE3-SONET] PWs. 132 It can be used for setup of all types of TDM PWs without any changes 133 in its encoding (see [PWE3-IANA]) with the following semantics: 135 1. For Structure-agnostic emulation the payload type can be any 136 value. 137 2. For CESoPSN PWs: 138 a. The specified value MUST be an integer multiple of number of 139 DS0 channels in the corresponding attachment circuit. 140 b. For trunk-specific NxDS0 with CAS, (Payload Bytes/number of DS0 141 channels) must be an integer factor of the number of frames per 142 corresponding trunk multiframe 143 3. For TDMoIP the Payload Bytes must be an integer multiple of 48 145 L2TP TDM October 2004 147 The R bit defines the present of the RTP header. If the R bit is 1 148 then the RTP header is present and the RTP AVP MUST appear. If the R 149 bit is zero then the RTP header is not used. 151 The T bit is ignored and MUST be set to zero. 153 The F bit indicates fragmentation when sending multiframe. The F bit 154 MUST be zero for all TDM PWs Types excluding trunk-specific NxDS0 155 services with CAS using the CESoPSN encapsulation. In case of these 156 services, the F bit MUST be set if the payload size specified value 157 differs from the number of frames per trunk multiframe. 159 2.2 RTP AVP [ICRQ, OCRQ, ICRP, OCRP] 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |M|H| rsvd | Length | Vendor Id [IETF] | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Attribute Type [TBD] |D| PT | Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Reserved | Timestamp Clock Frequency | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | SSRC | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 This AVP MUST appear only if the RTP header is used. 174 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 175 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 176 16. 178 The D bit indicates differential time stamping in the RTP header. If 179 the D bit is set to 1 then the time stamping is differential. 180 Otherwise absolute time stamping is used. Differential mode can be 181 used only if both sides use RTP and use differential time stamping. 183 PT is the payload type expected in the RTP header. Value of zero 184 indicates that the payload type is ignored and will not be used to 185 detect malformed packets. 186 Timestamp Clock Frequency is the clock frequency used for the time 187 stamping in 8 KHz. 189 SSRC indicates the expected value of SSRC ID in the RTP header. A 190 zero in this field means that SSRC ID will not be used for detecting 191 misconnections. Since L2TP provides an alternative security mechanism 192 via the cookies, if the cookie length is larger then zero the SSRC 193 SHOULD be zero. 195 L2TP TDM October 2004 197 2.3 Changes in the Control Connection AVPs 199 Control Connection that support TDM MUST add the appropriate PW Type 200 value to the list in the Pseudowire Capabilities List AVP. The exact 201 value is TBD by IANA and is listed in the next section. 203 2.4 Changes in the Session Connection AVPs 205 PW Type AVP should be set to one of the following values: 206 1. Structure-agnostic emulation [PWE3-SATOP] of: 207 a. E1 circuits - TBA by IANA 208 b. T1 circuits - TBA by IANA 209 c. E3 circuits - TBA by IANA 210 d. T3 circuits - TBA by IANA 211 2. Structure-aware emulation [PWE3-CESoPSN], [PWE3-TDMoIP] of: 212 a. CESoPSN basic mode - TBA by IANA 213 b. TDMoIP basic mode - TBA by IANA 214 c. CESoPSN service with CAS - TBA by IANA 215 d. TDMoIP with CAS - TBA by IANA 217 TDM pseudowires use their own control word. Therefore the L2- 218 Specific Sublayer AVP MUST either be omitted or set to zero. 220 TDM pseudowires use their own sequencing. Therefore the Data 221 Sequencing AVP MUST either be omitted or set to zero. 223 3. Creation of the TDM Pseudowire Session 225 When LCCE wants to open a Session for TDM PW it should include the 226 TDM PW AVP and the RTP AVP (if needed) in the ICRQ or OCRQ message. 227 The LCCE peer must validate that TDM PW AVP and make sure it can 228 supply the requirements derived from the RTP AVP (if any exist). If 229 the peer agrees with the CESoPSN AVP it will send an appropriate ICRP 230 or OCRP message with RTP AVP (if needed). The Initiator need to 231 validate that it can supply the requirements derived from the 232 received RTP AVP. 234 The two peers MUST agree on the values in the TDM PW AVP: 235 1. Bit Rate MUST be equal on both sides. 236 2. The Flavor bit MUST be equal on both sides 237 3. The Payload Bytes and the R bit MAY NOT be the same. 239 4. IANA Considerations 241 This draft requires assignment of the following values by IANA: 243 1. PW types listed in Section 2.1 above. 244 2. New attribute IDs for TDM PW and and RTP AVPs. 246 L2TP TDM October 2004 248 Security Considerations 250 There are no additional security considerations on top of the ones 251 discussed in [L2TP] 253 Copyright notice 255 Copyright (C) The Internet Society (2004). This document is subject 256 to the rights, licenses and restrictions contained in BCP 78, and 257 except as set forth therein, the authors retain all their rights. 259 This document and the information contained herein are provided on an 260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 262 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 263 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 264 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 References 269 [RFC2026] Bradner, S., "The Internet Standards Process -- 270 Revision 3", BCP 9, RFC 2026, October 1996. 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997 275 [L2TP] J. Lau, M. Townsley, I. Goyret , Layer Two Tunneling 276 Protocol (Version 3), Work in Progress, draft-ietf- 277 l2tpext-l2tp-base-14.txt, June 2004 279 [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit 280 Emulation Service over Packet Switched Network 281 (CESoPSN), Work in progress, July 2004, draft-ietf- 282 pwe3-cesopsn-01.txt 284 [PWE3-SATOP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over 285 Packet (SAToP), Work in Progress, December 2003, 286 draft-ietf-pwe3-satop-01.txt 288 [PWE3-TDMoIP] Y. Stein et al, TDM over IP, Work in progress, draft- 289 ietf-pwe3-tdmoip-01.txt, February 2004. 291 [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo 292 Wire Edge to Edge Emulation (PWE3), Work in progress, 293 October 2004, draft-ietf-pwe3-iana-allocation-07.txt 295 L2TP TDM October 2004 297 Acknowledgments 299 I thank Alexander ("Sasha") Vainshtein for reviewing this text. 301 Author's Addresses 303 Sharon Galtzur 304 Axerra Networks 305 24 Raoul Wallenberg St., 306 Tel Aviv 69719, Israel 307 Email: sharon@axerra.com