idnits 2.17.1 draft-ietf-pppext-l2tp-mpls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... o MUST, SHALL, or MANDATORY -- ...' RFC 2119 keyword, line 102: '... o SHOULD or RECOMMEND -- This i...' RFC 2119 keyword, line 105: '... o MAY or OPTIONAL -- This item ...' RFC 2119 keyword, line 121: '...otocol Label AVP MAY be present in ICR...' RFC 2119 keyword, line 123: '... Mlabel SHOULD be used for all packe...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 168, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-13 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-04 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-02 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-03 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-bgp4-mpls-02 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Informational Sun Microsystems, Inc. 4 Title: draft-ietf-pppext-l2tp-mpls-02.txt Ken Peirce 5 Date: February 1999 3Com Corporation 7 Layer Two Tunneling Protocol "L2TP" 8 Multi-Protocol Label Switching Extension 10 Status of this Memo 12 This document is a submission by the PPP Extensions Working Group of 13 the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the l2tp@ipsec.org mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-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: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The L2TP document [1] defines the base protocol which describes the 40 method of tunneling PPP [2] data. The L2TP base protocol does not 41 address any MPLS extensions. 43 The goal of MPLS is to speed forwarding of packets by reducing the 44 lookup required in routing. This draft proposes a method to allow 45 L2TP Data Sessions to be assigned a Multi-Protocol Label. 47 Table of Contents 49 1.0 Introduction 50 1.1 Conventions 51 2.0 Multi-Protocol Label Switching 52 2.1 Multi-Protocol Label AVP 53 2.2 Error Reporting 54 3.0 References 55 4.0 Acknowledgements 56 5.0 Authors' Addresses 58 1.0 Introduction 60 The L2TP protocol specification does not discuss Multi-Protocol Label 61 Switching(MPLS) [4] in any way. This document will describe how two 62 L2TP peers can negotiate an Multi-Protocol Label (Mlabel) for an L2TP 63 session. This will provide either the LNS or LAC with an Mlabel with 64 which to initiate the creation of an MPLS Label Switched Path to the 65 peer. The application of an MPLS should speed the forwarding of the 66 L2TP packets by reducing the header analysis/lookup. 68 This L2TP extension allows individual sessions within a tunnel to 69 have their own Mlabel. 71 Note that this document does not cover the negotiation of the LSP. 72 This is a function of either the Label Distribution Protocol [5] or a 73 routing protocol(like BGP)[6] with extensions. However, having the L3 74 address and it's contextually meaningful Mlabel should provide the 75 components needed to use an LSP regardless of the label distribution 76 mechanism used. 78 The mechanism defined in this document assumes that the Tunnel 79 Initiator determines what the user's appropriate label is and sends 80 the value in either the ICRQ or OCRQ messages. 82 The Tunnel Terminator can respond to the message by stating what it 83 believes is the user's appropriate label. 85 In the case where the Tunnel Terminator does not propose ANY 86 indicator (which is infered by the absence of the MPLS AVPs in either 87 the ICRP or OCRP) the Tunnel Initiator will assume its Mlabel is 88 acceptable or, if it did not send one in the ICRQ or OCRQ, that no 89 Mlabel is assigned to the session. 91 A tunnel peer which violates the negotiated label value is unlikely 92 to successfully create an LSP. 94 1.1 Conventions 96 The following language conventions are used in the items of 97 specification in this document: 99 o MUST, SHALL, or MANDATORY -- This item is an absolute 100 requirement of the specification. 102 o SHOULD or RECOMMEND -- This item should generally be followed 103 for all but exceptional circumstances. 105 o MAY or OPTIONAL -- This item is truly optional and may be 106 followed or ignored according to the needs of the implementor. 108 2.0 Multi-Protocol Label Switching 110 This section will define the new AVP which is required for the MPLS 111 label distribution extension of the L2TP protocol. The AVP allows the 112 designation of an Mlabel for a specific data channel or group of data 113 channels. 115 2.1 Multi-Protocol Label AVP 117 The Mlabel is an opaque object for an L2TP session used in a method 118 similar to [5]. The following AVP holds the Mlabel without any 119 knowledge of its composition. 121 The Multi-Protocol Label AVP MAY be present in ICRQ, ICRP, OCRQ and 122 OCRP. This message is used to inform the tunnel peer that a specific 123 Mlabel SHOULD be used for all packets related to the data channel 124 associated with the Tunnel and Call Identifiers in the L2TP header 125 [1]. 127 A tunnel peer which violates the negotiated label value is unlikely 128 to successfully create an LSP. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |1|1|0|0| Length | 43 | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | 1 | Multi-Protocol Label Value | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Multi-Protocol Label Value | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 This AVP MAY be present in the messages shown above. It is encoded 141 with a Vendor ID of 43 (3Com Corporation) with the attribute set to 142 2, marked as optional, with the indicator value as data. This AVP 143 SHOULD NOT be hidden and is optional. When present, the L2TP peer is 144 indicating that Multi-Protocol Labels are to be used at the link 145 layer. 147 2.2 Error Reporting 149 In the event that the peer did not accept the Mlabel provided, or is 150 unable to support MPLS a Call-Disconnect-Notify is returned to the 151 peer. 153 If the Mlabel provided cannot be used by the peer, the Call- 154 Disconnect-Notify message will include the Multi-Protocol Label AVP 155 as provided in the message that caused the Call-Disconnect-Notify. 157 3.0 References 159 [1] W.M. Townsley, A. J. Valencia, A. Rubens, G.S. Pall, G. Zorn, 160 B. Palter, "Layer Two Tunneling Protocol (L2TP)", 161 draft-ietf-pppext-l2tp-13.txt, Work in Progress, January 1999. 163 [2] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, 164 T. Li, A. Conta, "MPLS Label Stack Encoding", 165 draft-ietf-mpls-label-encaps-03.txt, Work in Progress, 166 March 1999. 168 [3] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 169 Switching Architecture", draft-ietf-mpls-arch-04.txt, 170 Work in Progress, February 1999. 172 [4] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, 173 A. Viswanathan, "A Framework for Multiprotocol Label 174 Switching", draft-ietf-mpls-framework-02.txt, Work in 175 Progress, November 1997. 177 [5] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP 178 Specification", draft-ietf-mpls-ldp-03.txt. Work in 179 Progress, January 1999. 181 [6] Rekhter, Rosen, "Carrying Label Information in BGP-4", 182 draft-ietf-mpls-bgp4-mpls-02.txt, Work in Progress, 183 August 1999. 185 4.0 Acknowledgements 187 The Authors would like to acknowledge John Shriver for his useful 188 comments to an earlier version of this document. 190 5.0 Authors' Addresses 192 Questions about this memo can be directed to: 194 Pat R. Calhoun 195 Network and Security Research Center, Sun Labs 196 Sun Microsystems, Inc. 197 15 Network Circle 198 Menlo Park, California, 94025 199 USA 201 Phone: 1-650-786-7733 202 Fax: 1-650-786-6445 203 E-mail: pcalhoun@eng.sun.com 205 Ken Peirce 206 3Com Corporation 207 1800 Central Ave. 208 Mount Prospect, Il, 60056 210 Phone: 1-847-342-6894 211 Fax: 1-847-222-2424 212 E-mail: Ken_Peirce@mw.3com.com