Naveen Gowda INTERNET DRAFT Elwin Stelzer Corona Networks, Inc. Umesh Sirsiwal Avian Communications, Inc. June 2001 L2TP Session Update Mechanism 1.0 Status of this Memo 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. 2.0 Abstract Once a L2TP session is established, the current standard [RFC 2661] has no explicit mechanism to update the session characteristics, during the life of the session, between the L2TP tunnel endpoints. One such requirement for this mechanism is, LNS informing LAC about the PPP-user's service characteristics, so that user-specific service actions can be applied at LAC. Eg: DSCP marking. There is a need for additional messages that will address similar requirements. Two additional messages are defined in this draft for this. Naveen, et al. [Page 1] INTERNET-DRAFT L2TP Session Update Mechanism June 2001 3.0 Table of Contents 1.0 Status of this Memo .................................... 1 2.0 Abstract ............................................... 1 3.0 Table of Contents ...................................... 2 4.0 Specification of Requirements .......................... 2 5.0 Introduction ........................................... 2 6.0 Session Characteristics Update Messages ................ 2 6.1 SURQ ................................................... 2 6.2 SURP ................................................... 3 7.0 L2TP Extension AVP (LEX-AVP) ........................... 3 8.0 Summary and Conclusions ................................ 4 9.0 IANA Considerations .................................... 4 10.0 Security Considerations ................................ 4 11.0 Acknowledgement ........................................ 5 12.0 References ............................................. 5 13.0 Authors' Addresses ..................................... 5 4.0 Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 5.0 Introduction Following additional messages are defined to exchange session characteristics: Session-Update-Request (SURQ) Session-Update-Reply (SURP) The SURQ is sent either from LAC to LNS or LNS to LAC. On receiving this the recipient responds by sending SURP. SURP contains the recognized and processed AVPs from SURQ. These messages can be used for user-specific service information to be exchanged between LAC and LNS, even after the session is established. 6.0 Session Characteristics Update Messages 6.1 Session-Update-Request (SURQ) Message The Session-Update-Request is sent by the LNS/LAC to update peer regarding session parameters. SURQ message is sent only after session establishment is successful. In case of LNS this message can be sent after receving ICCN or sending OCCN, and the session reaching the established state. In case of LAC this message can be sent after sending ICCN or receiving OCCN, and the session reaching Naveen, et al. [Page 2] INTERNET-DRAFT L2TP Session Update Mechanism June 2001 the established state. Recipient MUST be able to update its session information, if required be, based on SURQ. The attribute value for Message Type AVP is TBD. The Mandatory bit for this AVP MUST be Zero, so that the session can continue even when the peer can not recognize this message. Other existing or new AVPs can be added to the list of optional AVPs in this message as and when required. The following AVPs MUST be present in the SURQ: Message Type 6.2 Session-Update-Reply (SURP) Message The Session-Update-Reply is sent by LAC/LNS to inform the peer about the acceptance of the information in SURQ received earlier. SURP contains the recognized and processed AVPs in the same order as received in SURQ. Recipient MUST be able to update its session information, if required, based on SURP. The attribute value for Message Type AVP is TBD and the Mandatory bit for this AVP MUST be Zero. Other existing or new AVPs can be added to the list of optional AVPs in this message as and when required. The following AVPs MUST be present in the SURP: Message Type 7.0 L2TP Extension AVP (LEX-AVP) The L2TP Extesion AVP, Attribute Type TBD, describe the L2TP extension support capability of a system. This AVP can be sent in SCCRQ and/or SCCRP messages. Tunnel initiator can send this AVP to indicate to the peer regarding the extensions it supports and peer can also send its extension support through this AVP in SCCRP. After processing this AVP both the system can learn about the peer's capability to support different L2TP extensions and behave based on the results. Naveen, et al. [Page 3] INTERNET-DRAFT L2TP Session Update Mechanism June 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | L2TP ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Extension Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M bit MUST be set to 0 and this AVP can be hidden (H-bit set to 0 or 1). Length (before hiding) is 10 octets. Vendor ID is TBD. Attribute Type is 2 octet in length and its value is TBD. The L2TP Extension Capabilities field is a 32-bit bit-map representing the list of L2TP extensions supported. Each bit corresponds to one L2TP extension, and the bit being set indicates the appropriate extension is being supported. This also implies all the unallocated bits to be cleared. The extensions mentioned in this draft uses the bit-0 in this field. So, any implementation supporting this draft, needs to have bit-0 set. 8.0 Summary and Conclusions It is possible to change the session parameters during the life of session without restarting the session, using the SURQ and SURP messages. The LEX-AVP can be used to inform the peer about the list of supported L2TP extensions. 9.0 IANA Considerations Should this document advance on as standards track official attribute values need to be assigned for the LEX-AVP. Also message type needs to be assigned for SURQ and SURP. 10.0 Security Considerations This document does not introduce any new security issues beyond those inherent in L2TP, and may use the same mechanisms proposed for those technologies, where applicable. Naveen, et al. [Page 4] INTERNET-DRAFT L2TP Session Update Mechanism June 2001 11.0 Acknowledgments The authors thank W. Mark Townsley for his comments and help. 12.0 References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14 and RFC 2119, March 1997. [RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 13.0 Authors' Addresses Naveen PN Gowda Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: naveenietf@yahoo.com Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: elwinietf@yahoo.com Umesh Sirsiwal Avian Communications, Inc. 67 Forest Street, Marlborough, MA 01752 Email: umesh@aviancommunications.com Naveen, et al. [Page 5]