idnits 2.17.1 draft-ietf-l2tpext-tunnel-switching-08.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 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. 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 ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - STACKABLE AVP: Multiple instances of this AVP exist in the incoming message, each representing a hop in the tunnel switched path in order from first to last. When a TSA receives it, all the instances of AVP are copied as-is for the negotiation of the next hop. A locally generated AVP is appended to the outgoing message. If no value is appropriate then an AVP with a null value, as determined by the AVP definition, MUST be appended. However, If TSA couldn't copy all of incoming AVPs then it MUST not copy any one of them and drop all of the instances. If this is an AVP required to establish the tunnel or session and TSA cannot copy all of the stacked AVPS, then TSA MUST terminate the connection or session as appropriate. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) - Data sequencing AVP (Attribute Type 70) is a L2TPV3 AVP equivalent to the Sequencing required AVP (Attribute Type 39) in L2TPv2. In L2TPv3, any endpoint (LAC or LNS i.e. LCCE) can send the Data Sequencing AVP with the value 0 (no sequencing), 1 (sequencing only for non-ip packets) or 2 (sequencing for all the packets). In L2TPv2, only LAC can send the Sequencing Required AVP that requests the sequencing for all the packets. If data sequencing is enabled on the First session, then TSA should enable it on the Second session by sending the appropriate AVP (i.e. REGENERATED). If data sequencing is enabled on the First session, then TSA MAY choose (as decided by the local policy) not to enable the sequencing on Second session i.e. DROPPED. TSA SHOULD not enforce the sequencing but should send the data sequencing AVP on the Second session, if it's enabled on the First session. There is no requirement to have all hops use the consistent sequencing configuration. As always TSA's local policy would take precedence over the default behavior of "REGENERATED or DROPPED" -- 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 1, 2007) is 6259 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) == Outdated reference: A later version (-08) exists of draft-ietf-l2tpext-l2tp-ppp-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Kelkar 2 Internet Draft T. Mistretta 3 Intended status: Standards Track P. Howard 4 Expires: September 2007 Juniper Networks 5 V. Jain 6 Riverstone Networks 7 March 1, 2007 9 PPP over L2TP Tunnel Switching 10 draft-ietf-l2tpext-tunnel-switching-08.txt 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 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Distribution of this document is unlimited. Please send comments to 36 the Layer Two Tunneling Protocol Extensions (l2tpext) working group 37 at l2tpext@ietf.org. 39 Abstract 41 PPP [7] over L2TP Tunnel Switching, also called L2TP Multihop, is the 42 process of forwarding PPP payload from an L2TP session to another 43 L2TP session over a different tunnel. It facilitates moving the 44 logical termination point of an L2TP session, based on layer 2 45 characteristics or administrative policies, to different L2tp 46 Endpoint. This document introduces the L2TP tunnel switching 47 nomenclature and defines the behavior of standard AVPs in tunnel 48 switching deployment. The scope of this document is limited to the 49 discussion of switching PPP frames over L2TPv2 or L2TPv3 tunnels. 51 Table of Contents 53 1. Introduction...................................................3 54 2. L2TPv2 to L2TPv3 switch........................................4 55 3. AVP Behavior...................................................4 56 3.1. IETF Vendor AVPs..........................................5 57 4. Loop Detection................................................11 58 5. CDN Messages and L2TP tunnel Switching........................12 59 6. IANA Considerations...........................................12 60 6.1. Control Message Attribute Value Pairs (AVPs).............12 61 6.2. Result Code AVP Values...................................13 62 7. Security Considerations.......................................13 63 8. Intellectual Property Statement...............................13 64 9. Copyright Statement...........................................14 65 10. Acknowledgments..............................................14 66 11. References...................................................15 67 11.1. Normative References....................................15 68 11.2. Informative References..................................15 69 Author's Addresses...............................................16 71 Terminology 73 Tunnel Switching Aggregator (TSA): These are the devices that switch 74 the layer 2 payload from a first L2TP session/tunnel on to second 75 L2TP session/tunnel. 77 First Tunnel: The first L2tp Tunnel to be established at the TSA. 79 Second Tunnel: The second L2TP Tunnel to be established at the TSA. 81 First Session: The first L2tp Session to be established at the TSA. 83 Second Session: The second L2TP Session to be established at the TSA. 85 L2TP Control Connection Endpoint (LCCE): An L2TP node that exists at 86 either end of an L2TP control connection. May also be referred to as 87 an LAC or LNS, depending on whether tunneled frames are processed at 88 the data link (LAC) or network layer (LNS). 90 L2TP, as defined in [1], is now referred to as "L2TPv2," while the 91 extended version defined in [2] is referred to as "L2TPv3". The 92 remainder of this document will refer simply to L2TP in general, 93 unless contrasting specific features of L2TPv2 or L2TPv3, which may 94 differ in function. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [10]. 100 1. Introduction 102 L2TP allows processing of PPP packets to be divorced from the 103 termination of the layer 2 circuit. L2TP tunnel switching 104 facilitates moving the termination point of a PPP session further on 105 to another LCCE that is possibly unknown to the originating LCCE. It 106 does so by re-tunneling the PPP session within another L2TP tunnel to 107 a different LCCE. The knowledge of whether to switch a PPP session to 108 another L2TP tunnel can be static or dynamic (for example, during PPP 109 session establishment). 111 At the TSA, First and Second sessions are two discrete entities. The 112 First session is established in the beginning and then TSA uses the 113 negotiated parameters of the First session as a basis to negotiate 114 the Second session. If the Second session fails to negotiate then it 115 should be terminated. Same thing can be said for the tunnel. 117 PPP LAC TSA LNS 118 User [LNS LAC] 119 |---- PPP----| | | | 120 | |---- PPP/L2TP ----| | | 121 | | |-- PPP --| | 122 | | | |----- PPP/L2TP -----| 123 | | |<----- tunnel switching ----->| 124 | | | | | 125 | |<--First tunnel-->| |<--Second tunnel--->| 127 Figure 1: L2TP tunnel Switching for incoming calls 129 The figure above presents a typical tunnel switching scenario for 130 incoming calls. The user opens a PPP session to a LAC, which tunnels 131 the session to TSA as defined by L2TP protocol. The TSA, based on 132 the local policies, determines if the First session should be further 133 tunneled. If the TSA decides to tunnel the session further, then, 134 for every such session it initiates another session onto another L2TP 135 tunnel originating on the TSA terminating on a different LNS. Once 136 the session is established, the data packets are switched from an 137 incoming tunnel to a corresponding outgoing tunnel. 139 2. L2TPv2 to L2TPv3 switch 141 If First and Second tunnels use different versions of L2TP protocol 142 at TSA i.e. if it involves a 'version switch', then it must adapt the 143 data encapsulation change. 145 +------------------------+ +----------------------------+ 146 | PPP Tunneled Frame | | PPP Tunneled Frame | 147 | | | | 148 +------------------------+ +----------------------------+ 149 | | | Default L2-Specific | 150 | | | Sublayer | 151 | L2TPv2 Data Header | | (Ref [6] section 4.1) | 152 | over UDP | +----------------------------+ 153 | (Ref [1] section 3.1) | | L2TPv3 Data Session | 154 | | | Header over UDP or IP | 155 | | | (Ref [2] section 4.1.1.1 | 156 | | | and 4.1.2.1) | 157 +------------------------+ +----------------------------+ 158 | L2TPv2 Data Channel | | L2TPv3 Data Channel | 159 | (unreliable) | | (unreliable) | 160 +------------------------+----+----------------------------+ 161 | Packet-Switched Network (UDP, IP, FR, MPLS, etc.) | 162 +----------------------------------------------------------+ 164 Figure 2: L2TPv2 to L2TPv3 data encapsulation switch 166 When PPP frames, which are encapsulated in the L2TPv2 header, are 167 received at the TSA and are switched to Second tunnel using L2TPv3, 168 then L2TPv2 headers are stripped and PPP frame is encapsulated with 169 the L2TPv3 data header followed by the optional Default L2-Specific 170 Sublayer and Offset Padding (Ref [6] section 4.2) fields, and 171 forwarded over the session. 173 The version switch may involve a transport change i.e. L2TPv3-IP to 174 L2TPv2-UDP. TSA MUST be able to adapt to such change. 176 3. AVP Behavior 178 An AVP negotiated by the First tunnel/session MUST be handled in four 179 ways - it could be relayed, dropped, regenerated, or stacked. They 180 are defined as follows. 182 - RELAYED AVP: (also known as pass-through AVP) AVP is forwarded 183 transparently if it was negotiated by the First tunnel/session. 185 - DROPPED AVP: AVP is dropped if it was negotiated by the First 186 tunnel/session. 188 - REGENERATED AVP: AVP negotiated by the First tunnel/session is 189 ignored upon receipt. A new AVP is regenerated for the Second 190 tunnel/session based on the local policy at the TSA. The local 191 policy may or may not use the received AVP to regenerate the new 192 value. The regenerated value MAY match with the received AVP value. 194 - STACKABLE AVP: Multiple instances of this AVP exist in the incoming 195 message, each representing a hop in the tunnel switched path in order 196 from first to last. When a TSA receives it, all the instances of AVP 197 are copied as-is for the negotiation of the next hop. A locally 198 generated AVP is appended to the outgoing message. If no value is 199 appropriate then an AVP with a null value, as determined by the AVP 200 definition, MUST be appended. However, If TSA couldn't copy all of 201 incoming AVPs then it MUST not copy any one of them and drop all of 202 the instances. If this is an AVP required to establish the tunnel or 203 session and TSA cannot copy all of the stacked AVPS, then TSA MUST 204 terminate the connection or session as appropriate. 206 3.1. IETF Vendor AVPs 208 This section defines the behavior of AVPs according to the guidelines 209 in section 3. It describes the behavior of AVPs defined in [1], [2], 210 [3], [4], [5], [6], and [8]. All the future AVP extensions MUST 211 define AVP behavior for tunnel switching. 213 An optional AVP whose behavior is defined as RELAYED, MUST be RELAYED 214 only if the AVP is negotiated by the First tunnel/session. Hence the 215 behavior for such AVP is stated as 'RELAYED if negotiated by the 216 first tunnel/session'. 218 An optional AVP whose behavior is defined as REGENERATED, could be 219 DROPPED from the negotiation of the Second tunnel/session at the 220 TSA's discretion. Hence the behavior for such AVP is stated as 221 'REGENERATED or DROPPED' 223 In its default behavior TSA needs to be as transparent as possible. 224 However, TSA shouldn't prevent local policies to override the default 225 behavior and allow regeneration of the AVPs mentioned as 226 'REGENERATED'. 228 Message Type (All Messages) - MUST be REGENERATED 230 Result Code (CDN, StopCCN) - MUST be either RELAYED or REGENERATED 231 based on recommendations discussed in section 5. In case of version 232 switch, if L2TPv3 Result Codes and Error Codes are RELAYED then they 233 MUST be translated into general error (Result Code 2, Error Code 0). 235 Protocol Version (SCCRQ, SCCRP) - MUST be REGENERATED. This would 236 allow TSA to switch sessions when the First and Second tunnels use 237 different versions of the L2TP protocol. 239 Framing Capabilities (SCCRQ, SCCRP) - MUST be REGENERATED. 241 Bearer Capabilities (SCCRQ, SCCRP) - MUST be either REGENERATED or 242 DROPPED. 244 Tie Breaker (SCCRQ) - MUST be either REGENERATED or DROPPED. 246 Firmware Revision (SCCRP, SCCRQ) - MUST be either REGENERATED or 247 DROPPED. 249 Host Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED. 251 Vendor Name (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED. 253 Assigned tunnel ID (SCCRP, SCCRQ, StopCCN) - MUST be REGENERATED. 255 Receive Window Size (SCCRQ, SCCRP) - MUST be either REGENERATED or 256 DROPPED. 258 Challenge (SCCRP, SCCRQ) - MUST be either REGENERATED or DROPPED. 260 Q.931 Cause Code (CDN) - MUST be either RELAYED if negotiated by the 261 First session or DROPPED. 263 Challenge Response (SCCCN, SCCRP) - MUST be either REGENERATED or 264 DROPPED. 266 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) - MUST be 267 REGENERATED. 269 Call Serial Number (ICRQ, OCRQ) - MUST be RELAYED. It would best 270 serve the intended purpose of this AVP and facilitate easier 271 debugging. 273 Minimum BPS (OCRQ) - MUST be RELAYED if negotiated by the First 274 session. In case of version switch, TSA should relay it as a Tx 275 Minimum Speed AVP (Ref [6]) 276 Maximum BPS (OCRQ) - MUST be RELAYED if negotiated by the First 277 session. In case of version switch, TSA should relay it as a Tx 278 Maximum Speed AVP (Ref [6]) 280 Bearer Type (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the First 281 session. 283 Framing Type (ICCN, OCCN, OCRQ) - MUST be RELAYED. 285 Called Number (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the 286 First session. 288 Calling Number (ICRQ) - MUST be RELAYED if negotiated by the First 289 session. 291 Sub-Address (ICRQ, OCRQ) - MUST be RELAYED if negotiated by the First 292 session. 294 Tx Connect Speed (ICCN, OCCN) - MUST be RELAYED. In case of version 295 switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type 296 74). 298 Physical Channel ID (ICRQ, OCRP) - MUST be either RELAYED if 299 negotiated by the First session, REGENERATED, or DROPPED. 301 Proxy LCP AVPs (ICCN) - All the Proxy LCP AVPs (Initial Received LCP 302 CONFREQ, Last Sent LCP CONFREQ and Last Received LCP CONFREQ) MUST be 303 either all RELAYED, all REGENERATED or all DROPPED. If an AVP is 304 REGENERATED then it would mean the LCP was renegotiated; whereas, 305 RELAYED conveys the fact that it was passed along and was not 306 renegotiated. 308 Proxy Authentication AVPs (ICCN) - All the Proxy Authentication AVPs 309 (Proxy Authen Type, Proxy Authen Name AVP, Proxy Authen Challenge 310 Proxy Authen ID and Proxy Authen Response AVP) MUST be either all 311 RELAYED, all REGENERATED, or all DROPPED. If an AVP is REGENERATED 312 then it would mean the Authentication was renegotiated; whereas, 313 RELAYED conveys the fact that it was passed along and was not 314 renegotiated. 316 Call Errors (WEN) - MUST be RELAYED. 318 ACCM (SLI) - MUST be RELAYED. 320 Random Vector (All Messages) - MUST be either REGENERATED or DROPPED. 322 Private Group ID (ICCN) - MUST be RELAYED if negotiated by the First 323 session. 325 Rx Connect Speed (ICCN, OCCN) - MUST be RELAYED if negotiated by the 326 First session. In case of version switch, TSA should relay it as a 327 Rx Connect Speed AVP (Attribute Type 75). 329 Sequencing Required (ICCN, OCCN) - MUST be either REGENERATED or 330 DROPPED. In case of version switch, TSA should regenerate it as a 331 Data Sequencing AVP (Attribute Type 70). 333 Rx Minimum BPS (OCRQ) (Ref [8]) - MUST be RELAYED if negotiated by 334 the First session. In case of version switch, TSA should relay it as 335 a Rx Minimum Speed AVP (Ref [6]). 337 Rx Maximum BPS (OCRQ) (Ref [8]) - MUST be RELAYED if negotiated by 338 the First session. In case of version switch, TSA should relay it as 339 a Rx Maximum Speed AVP (Ref [6]). 341 PPP Disconnect Cause AVP (CDN) (Ref [3])- MUST be either RELAYED if 342 negotiated by the First tunnel/session or DROPPED if it's not 343 supported. 345 Control Connection DS AVP (SCCRQ, SCCRP) (Ref [4]) - MUST be either 346 RELAYED if negotiated by the First tunnel or DROPPED if it's not 347 supported. The value of this AVP could be chosen based on 'PHB Code' 348 used (or to be used) on the tunnels, which the TSA is going to be 349 switching tunnels to. TSA need not use same PHB-to-DSCP mappings on 350 a First tunnel and Second tunnel. 352 Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) (Ref [4]) - MUST be either 353 RELAYED if negotiated by the First session or DROPPED if it's not 354 supported. The value of this AVP could be chosen based on 'PHB Code' 355 used (or to be used) on the sessions, which the TSA is going to be 356 switching sessions to. TSA need not use same PHB-to-DSCP mappings on 357 a First session and Second session. 359 LCP Want Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if 360 negotiated by the First session or DROPPED if it's not supported. 362 LCP Allow Options (ICCN, OCCN) (Ref [5]) - MUST be either RELAYED if 363 negotiated by the First session or DROPPED if it's not supported. 365 Extended Vendor ID AVP (Version 3) (All Messages) - MUST be either 366 REGENERATED or DROPPED. 368 Message Digest AVP (Version 3) (All Messages) - MUST be either 369 REGENERATED or DROPPED. 371 Router Id AVP (Version 3) (SCCRQ, SCCRP) - MUST be either REGENERATED 372 or DROPPED. 374 Assigned Control Connection Id AVP (Version 3) (SCCRQ, SCCRP, 375 StopCCN) - MUST be either REGENERATED or DROPPED. 377 Pseudowire Capabilities List AVP (Version 3) (SCCRQ, SCCRP) - MUST be 378 either REGENERATED or DROPPED. 380 Local Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, 381 CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED. 383 Remote Session Id AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, 384 OCCN, CDN, WEN, SLI) - MUST be either REGENERATED or DROPPED. 386 Assigned Cookie AVP (Version 3) (ICRQ, ICRP, OCRQ, OCRP) - MUST be 387 either REGENERATED or DROPPED. 389 Remote End Id AVP (Version 3) (ICRQ, OCRQ) - MUST be either 390 REGENERATED or DROPPED. 392 Session Tie Breaker AVP (Version 3) (ICRQ, OCRQ) - MUST be either 393 REGENERATED or DROPPED. 395 Pseudowire Type AVP (Version 3) (ICRQ, OCRQ) - MUST be either 396 REGENERATED or DROPPED. 398 L2-specific Sublayer AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, 399 OCCN) - MUST be either REGENERATED or DROPPED. 401 Data Sequencing AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 402 - Data sequencing AVP (Attribute Type 70) is a L2TPV3 AVP equivalent 403 to the Sequencing required AVP (Attribute Type 39) in L2TPv2. In 404 L2TPv3, any endpoint (LAC or LNS i.e. LCCE) can send the Data 405 Sequencing AVP with the value 0 (no sequencing), 1 (sequencing only 406 for non-ip packets) or 2 (sequencing for all the packets). In L2TPv2, 407 only LAC can send the Sequencing Required AVP that requests the 408 sequencing for all the packets. If data sequencing is enabled on the 409 First session, then TSA should enable it on the Second session by 410 sending the appropriate AVP (i.e. REGENERATED). If data sequencing 411 is enabled on the First session, then TSA MAY choose (as decided by 412 the local policy) not to enable the sequencing on Second session i.e. 413 DROPPED. TSA SHOULD not enforce the sequencing but should send the 414 data sequencing AVP on the Second session, if it's enabled on the 415 First session. There is no requirement to have all hops use the 416 consistent sequencing configuration. As always TSA's local policy 417 would take precedence over the default behavior of "REGENERATED or 418 DROPPED" 420 Circuit Status AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, 421 SLI) - MUST be either REGENERATED or DROPPED. 423 Preferred Language AVP (Version 3) (SCCRQ, SCCRP) - MUST be either 424 REGENERATED or DROPPED. 426 Tx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 427 - MUST be either RELAYED, REGENERATED or DROPPED. In case of version 428 switch, TSA should relay it as a Tx Connect Speed AVP (Attribute Type 429 24). If value is greater than 4 octets, it SHOULD be dropped. 431 Rx Connect Speed AVP (Version 3) (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 432 - MUST be either RELAYED if negotiated by the First session, 433 REGENERATED or DROPPED. In case of version switch, TSA should relay 434 it as a Rx Connect Speed AVP (Attribute Type 38). If value is 435 greater than 4 octets, it SHOULD be dropped. 437 Offset Size (Version 3) (ICRQ, ICRP, ORCQ, OCRP) (Ref [6]) - MUST be 438 either REGENERATED or DROPPED. 440 Tx Minimum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either 441 RELAYED, REGENERATED or DROPPED. In case of version switch, TSA 442 should relay it as a Minimum BPS AVP (Attribute Type 16). If value 443 is greater than 4 octets, it SHOULD be dropped. 445 Tx Maximum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either 446 RELAYED, REGENERATED or DROPPED. In case of version switch, TSA 447 should relay it as a Maximum BPS AVP (Attribute Type 17). If value 448 is greater than 4 octets, it SHOULD be dropped. 450 Rx Minimum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either 451 RELAYED, REGENERATED or DROPPED. In case of version switch, TSA 452 should relay it as a Rx Minimum BPS AVP (Attribute Type 40). If 453 value is greater than 4 octets, it SHOULD be dropped. 455 Rx Maximum Speed AVP (Version 3) (OCRQ) (Ref [6]) - MUST be either 456 RELAYED, REGENERATED or DROPPED. In case of version switch, TSA 457 should relay it as a Rx Maximum BPS AVP (Attribute Type 41). If 458 value is greater than 4 octets, it SHOULD be dropped. 460 Failover Capability AVP (SCCRQ, SCCRP) (Ref [9]) - MUST be 461 REGENERATED based on the TSA's capabilities 462 Tunnel Recovery AVP (SCCRQ) (Ref [9]) - MUST be REGENERATED based on 463 failover negotiations with the peer on an individual tunnel. 465 Suggested Control Sequence AVP (SCCRP) (Ref [9]) - MUST be 466 REGENERATED based on failover negotiations with the peer on an 467 individual tunnel. 469 Failover Session State AVP (FSQ, FSR) (Ref [9]) - MUST be REGENERATED 470 based on failover negotiations with the peer on an individual tunnel. 472 TSA ID AVPs (defined in this document) - MUST be STACKED. The local 473 TSA ID AVP is stacked to the incoming set of TSA ID AVPs. 475 4. Loop Detection 477 The Tunnel Switching Aggregator (TSA) ID AVP, Attribute Type 93, 478 could be used to detect if a session is looping in an L2TP tunnel 479 switched network. This AVP MUST be STACKED. 481 If this AVP was received in an incoming control packet (ICRQ, OCRQ) 482 then the TSA MUST check to see if it's own TSA ID (a configured 483 value) is present in the stack of incoming TSA ID AVPs. Upon finding 484 a match, the TSA MUST respond with a CDN carrying a Result Code 485 indicating 'Loop Detected' 26, and optionally a description 486 indicating the loop condition. A match comparison MUST only be 487 performed if TSA has configured non-null TSA ID. 489 The Attribute Value field for this AVP has the following format: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | TSA ID ... (maximum 64 octets) 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 TSA ID is a configured value (human readable string) with a maximum 498 length of 64 octets. It is administratively controlled to ensure its 499 uniqueness among all the inter-connected LACs, LNSs and TSAs. If no 500 value is configured then the AVP value MUST be of length 0. 502 This AVP MUST be either hidden (the H-bit can be either 0 or 1). The 503 M-bit for this AVP MUST be set to 0. 505 5. CDN Messages and L2TP tunnel Switching 507 To identify error conditions explicitly in the multi-TSA environment, 508 new error codes are defined. Existing error codes are not used 509 because they might trigger an unwarranted behavior depending upon why 510 it was generated. Error codes are defined as follows: 512 Next hop unreachable (Result Code 2, Error Code 10) - TSA MUST 513 disconnect the First tunnel/session with this Error Code, if next hop 514 is unreachable and no other alternative paths are available as 515 determined by the local policy. 517 Next hop busy (Result Code 2, Error Code 11) - TSA MUST disconnect 518 the First tunnel/session with this Error Code, if next hop 519 disconnects the Second tunnel/session with an error code 'TSA Busy' 520 or other indications from next hop indicate that it is too busy to 521 take more tunnels/sessions and no other alternative paths are 522 available as determined by the local policy 524 TSA busy (Result Code 2, Error Code 12) - TSA MUST disconnect the 525 first tunnel/session with this Error Code, if it is congested or 526 temporarily running out of resources. 528 In the case of multiple levels of TSAs, error code SHOULD be 529 propagated back until it reaches either the original LCCE or an 530 intermediate TSA, which has an alternate path. On the receipt of 531 error code, local policy on the LCCE or the intermediate TSA should 532 handle the fallback and use it for the congestion recovery design. 534 6. IANA Considerations 536 6.1. Control Message Attribute Value Pairs (AVPs) 538 This number space is managed by IANA as per section 2.1 of [11]. 540 A summary of the new AVPs follows: 542 Control Message Attribute Value Pairs 544 Attribute 545 Type Description 546 --------- ------------------ 547 93 Tunnel Switching Aggregator ID AVP 549 6.2. Result Code AVP Values 551 New L2TP Result Codes appear in section 4 and 5, which need 552 assignment by IANA as described in section 2.3 of [11]. 554 Result Code AVP (Attribute Type 1) Values 555 ----------------------------------------- 556 Defined Result Code values for the CDN message are: 557 26 - Loop Detected 559 General Error Codes 560 10 - Next hop unreachable 561 11 - Next hop busy 562 12 - TSA busy 564 7. Security Considerations 566 TSA ID AVP could reveal the set of nodes that a given L2TP session is 567 traversing in the network. 569 If the AVPs described in this document are of concern then AVP 570 hiding, described in [1] MAY be used to help mitigate the security 571 threat; though it is not widely regarded as cryptographically secure, 572 [12] describes a more robust method for securing L2TP in general, and 573 should be used to encrypt all L2TP messages. 575 8. Intellectual Property Statement 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at ietf- 597 ipr@ietf.org. 599 9. Copyright Statement 601 Copyright (C) The IETF Trust (2007). 603 This document is subject to the rights, licenses and restrictions 604 contained in BCP 78, and except as set forth therein, the authors 605 retain all their rights. 607 This document and the information contained herein are provided on an 608 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 609 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 610 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 611 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 612 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 613 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 615 10. Acknowledgments 617 Authors gratefully acknowledge the valuable contributions of: Mark W. 618 Townsley, Reinaldo Penno, Ly Loi and Marc Eaton-Brown. We would like 619 to thank Carlos Pignataro for a thorough review. 621 11. References 623 11.1. Normative References 625 [1] RFC 2661, W. Townsley, A. Valencia, A. Rubens, G. Pall, G. 626 Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", August 1999. 628 [2] RFC 3931, J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 629 Protocol (Version 3)", March 2005. 631 [3] RFC 3145, Verma, et. al. "L2TP Disconnect Cause Information", 632 July 2001. 634 [4] RFC 3308, P. Calhoun, W. Luo, D. McPherson, K. Peirce, "Layer 635 Two Tunneling Protocol (L2TP) Differentiated Services 636 Extension", November 2002. 638 [5] RFC 3437, W. Palter, W. Townsley, "Layer-Two Tunneling Protocol 639 Extensions for PPP Link Control Protocol Negotiation", December 640 2002. 642 [6] C. Pignataro, Ed, "PPP Tunneling Using Layer Two Tunneling 643 Protocol Version 3" work in progress, draft-ietf-l2tpext-l2tp- 644 ppp-05.txt, November 2006. 646 [7] RFC 1661, W. Simpson, "The Point-to-Point Protocol (PPP)", STD 647 51, July 1994. 649 [8] RFC 3301, Y. T'Joens, B. Sales, P. Crivellari, "Layer Two 650 Tunneling Protocol (L2TP): ATM access network extensions", June 651 2002 653 [9] V. Jain, Ed, "Fail Over extensions for L2TP failover" work in 654 progress, draft-ietf-l2tpext-failover-12.txt, February 2007. 656 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 657 Levels", BCP 14, RFC 2119, March 1997. 659 11.2. Informative References 661 [11] BCP0068, Townsley, W., "Layer Two Tunneling Protocol (L2TP) 662 Internet Assigned Numbers Authority (IANA) Considerations 663 Update" RFC3438, BCP0068, December 2002 665 [12] RFC 3193, B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, 666 "Securing L2TP using IPsec", November 2001 668 Author's Addresses 670 Mahesh Kelkar 671 Juniper Networks 672 10 Technology Park Drive 673 Westford, MA 01886 674 Email: mkelkar@juniper.net 676 Tom Mistretta 677 Juniper Networks 678 10 Technology Park Drive 679 Westford, MA 01886 680 Email: tmistretta@juniper.net 682 Paul Howard 683 Juniper Networks 684 10 Technology Park Drive 685 Westford, MA 01886 686 Email: phoward@juniper.net 688 Vipin Jain 689 Riverstone Networks 690 5200 Great America Parkway 691 Santa Clara, CA 95054 692 Email: vipinietf@yahoo.com