Internet Draft INTERNET DRAFT Pat R. Calhoun Category: Informational Sun Microsystems, Inc. Title: draft-ietf-l2tpext-mpls-00.txt Ken Peirce Date: March 2000 Malibu Networks, Inc. Layer Two Tunneling Protocol "L2TP" Multi-Protocol Label Switching Extension Status of this Memo This document is a submission by the L2TP Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the l2tp@ipsec.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The L2TP document [1] defines the base protocol which describes the method of tunneling PPP data. The L2TP base protocol does not address any MPLS extensions. The goal of MPLS is to speed forwarding of packets by reducing the lookup required in routing. This draft proposes a method to allow Calhoun, Peirce expires September 2000 [Page 1] INTERNET DRAFT March 2000 L2TP Data Sessions to be assigned an MPLS Label Switched Path Id (LSPID)[3] for an explicit route (ER). Assignment of such an ER is necessary for traffic engineering. Table of Contents 1.0 Introduction 1.1 Conventions 2.0 Multi-Protocol Label Switching 2.1 Multi-Protocol LSPID AVP 2.2 Error Reporting 3.0 References 4.0 Acknowledgements 5.0 Authors' Addresses 1.0 Introduction The L2TP protocol specification does not discuss Multi-Protocol Label Switching (MPLS)[5] in any way. This document will describe how two L2TP peers can negotiate an LSPID for an L2TP over MPLS session. This will provide either the LNS or LAC with an LSPID with which to select an explicit MPLS Label Switched Path to the peer. The application of an LSPID should speed the forwarding of the L2TP packets by reducing the header analysis/lookup and permit effective traffic engineering. Note that this document does not cover the creation of the LSPID. This is a function of the Label Distribution Protocol[4]. MPLS explicit routes are uni-directional. Thus LSPIDs may be used to specify ERs in either or both the LAC-to-LNS and the LNS-to-LAC directions. The mechanism defined in this document assumes that the Tunnel Initiator SHALL determine what the user's appropriate LSPID is for LNS-to-LAC traffic and send that information in either the ICRQ or OCRQ messages. The Tunnel Terminator SHALL determine the appropriate LSPID for LAC- to-LNS traffic by including this information in the ICRP or OCRP. In the case where either one or both peers do not propose ANY LSPIDs, (which is inferred by the absence of the LSPID AVPs in the respective request and or response, it is assumed that the sending peer has no preference for the routing of the session traffic. A peer which fails to use an accepted LSPID in the routing of traffic MAY have its sessions(s) dropped. Calhoun, Peirce expires September 2000 [Page 2] INTERNET DRAFT March 2000 1.1 Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. 2.0 Multi-Protocol Label Switching This section will define the new AVP which is required for the MPLS label distribution extension of the L2TP protocol. The AVP allows the designation of an LSPID for a specific data channel or group of data channels. 2.1 Multi-Protocol LSPID AVP The LSPID is an opaque object for an L2TP session used in a method similar to [3]. The LSPID is defined in [3]. The following AVP holds the LSPID without any knowledge of its composition. The reader should note that the format of the LSPID is that of an MPLS TLV. However, that MPLS TLV is to be strictly treated as an opaque object by L2TP. The Multi-Protocol LSPID AVP MAY be present in ICRQ, ICRP, OCRQ and OCRP. This message is used to inform the tunnel peer that a specific MPLS ER SHOULD be used for all packets related to the data channel associated with the Tunnel and Call Identifiers in the L2TP header [1]. A peer which violates the routing of traffic in accordance with an accepted LSPID MAY have its sessions(s) dropped. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0|0| Length | 43 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | LSPID TLV[see 3] Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Peirce expires September 2000 [Page 3] INTERNET DRAFT March 2000 This AVP MAY be present in the messages shown above. It is encoded with a Vendor ID of 43 (3Com Corporation) with the attribute set to 2, marked as optional, with the indicator value as data. This AVP SHOULD NOT be hidden and is optional. When present, the L2TP peer is indicating that Multi-Protocol LSPIDs are to be used. 2.2 Error Reporting In the event that the peer did not accept the LSPID provided, or is unable to support MPLS a Call-Disconnect-Notify is returned to the peer. If the LSPID provided cannot be used by the peer, the Call- Disconnect-Notify message will include the Multi-Protocol LSPID AVP as provided in the message that caused the Call-Disconnect-Notify. 3.0 References [1] W.M. Townsley, A. J. Valencia, A. Rubens, G.S. Pall, G. Zorn, B. Palter. "Layer Two Tunneling Protocol (L2TP)", RFC 2661. August 1999. [2] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. Li, A. Conta. "MPLS Label Stack Encoding", draft-ietf-mpls- label-encaps-07.txt, IETF Work in Progress. September 1999. [3] Jamoussi et al. "Constraint-Based LSP Setup using LDP", draft- ietf-mpls-cr-ldp-03.txt, IETF Work in Progress. September 1999. [4] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. "LDP Specification", draft-ietf-mpls-ldp-06.txt, IETF Work in Progress. October 1999. [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan. "A Framework for Multiprotocol Label Switching", draft-ietf-mpls-framework-05.txt, IETF Work in Progress. September 1999. 4.0 Acknowledgements The Authors would like to acknowledge John Shriver for his useful comments to an earlier version of this document. 5.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Calhoun, Peirce expires September 2000 [Page 4] INTERNET DRAFT March 2000 Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.comt Ken Peirce Malibu Networks 1035 Suncast Lane, Suite 130 El Dorado Hills, CA, 95762 Phone: 1-916-941-8814 Fax: 1-916-941-8850 E-mail: Ken@malibunetworks.com Calhoun, Peirce expires September 2000 [Page 5]