Network Working Group N. McGill Internet-Draft C. Pignataro, Ed. Intended status: Standards Track Cisco Systems Expires: July 4, 2008 Jan 2008 L2TPv3 Extended Circuit Status Values draft-nmcgill-l2tpext-circuit-status-extensions-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on July 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines additional Layer 2 Tunneling Protocol (L2TPv3) bit values to be used within the "Circuit Status" Attribute-Value Pair (AVP) to communicate more granular error states for Access Circuits and Pseudowires. McGill & Pignataro Expires July 4, 2008 [Page 1] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 2. L2TP Extended Circuit Status Values . . . . . . . . . . . . . . 3 3. Clarifications . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 McGill & Pignataro Expires July 4, 2008 [Page 2] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 1. Introduction Currently the L2TPv3 Circuit Status AVP [RFC3931] is able to convey the UP/DOWN status of an access circuit. However, a finer granularity is often useful to determine the direction of the fault as has been added for MPLS-based pseudowires, see [RFC4446]. Additionally, it is useful (in redundancy scenarios) to be able to indicate if a pseudowire is in a standby state, where it is fully established but is not switching data. Again, such functionality is available for MPLS based pseudowires, see [I-D.muley-dutta-pwe3-redundancy-bit]. The proposal is to provide extended circuit status bit values for L2TPv3 and to add them in a manner such that it is backwards compatible with the current Circuit Status AVP. These new bits are applicable to all pseudowires types. 1.1. 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 [RFC2119]. 2. L2TP Extended Circuit Status Values The Circuit Status AVP (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI), Attribute Type 71, indicates the initial status of or a status change in the access circuit to which the session is bound. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |N|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (A) 0x0001 Local Attachment Circuit is up/active/ready (N) 0x0002 Notification is for a new circuit. Where, the A (Active) bit indicates whether the circuit is up/active/ ready (1) or down/inactive/not-ready (0). The N (New) bit is provided to emulate (Frame Relay) NNI signalling between PEs. It MAY be used to convey that a circuit has been McGill & Pignataro Expires July 4, 2008 [Page 3] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 reprovisioned or newly provisioned at the PE. It is uncertain as to what use the receiving PE can make of this bit, although it MAY include logging. It is proposed to deprecate this bit as it is of little or no use, hence this bit SHOULD be ignored on receipt and is OPTIONAL to send. For reference, see section 3.4 of [RFC4591] which does not specify any additional usage beyond the setting of in the ICRQ, ICRP and clearing in all other control messages. The proposal is to extend this bitmap of values to allow for finer granularity of status reporting. The new values are: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |S|E|I|T|R|0|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit Bit-Value Name -------------------------------------------------------------------- (A) 0x0001 Active: Pseudowire has no faults (R) 0x0004 Local Attachment Circuit (ingress) Receive Fault (T) 0x0008 Local Attachment Circuit (egress) Transmit Fault (I) 0x0010 Local PSN-facing PW (ingress) Receive Fault (E) 0x0020 Local PSN-facing PW (egress) Transmit Fault (S) 0x0040 Pseudowire is in standby mode Where the new bits values have the following meanings: (R), Local Attachment Circuit (ingress) Receive Fault Fault Here | | | +----------------------+ +----------------------+ | Rx| LCCE |Egress | Peer LCCE | --X-->| |-------->| | | L2TPv3 | | L2TPv3 | Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | <-----| |<--------| | +----------------------+ +----------------------+ An alarm or fault has occurred at the local attachment circuit such that it is unable to receive traffic. It can still transmit traffic. McGill & Pignataro Expires July 4, 2008 [Page 4] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 (T), Local Attachment Circuit (egress) Transmit Fault +----------------------+ +----------------------+ Rx| LCCE |Egress | Peer LCCE | ----->| |-------->| | | L2TPv3 | | L2TPv3 | Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | <--X--| |<--------| | | +----------------------+ +----------------------+ | | Fault Here A fault has occurred at the local attachment circuit such that it is unable to transmit traffic. It can still receive traffic. (I), Local PSN-facing PW (ingress) Receive Fault +----------------------+ +----------------------+ Rx| LCCE |Egress | Peer LCCE | ----->| |-------->| | | L2TPv3 | | L2TPv3 | Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | <-----| |<---X----| | +----------------------+ | +----------------------+ | | Fault Here A fault has occurred in the receive direction between the local endpoint and the remote L2TP endpoint. Note that a fault at the session level would not necessarily trigger a L2TP control channel timeout. The means of detecting this fault are outside the scope of this document; as an example, detection may be via BFD. (E), Local PSN-facing PW (egress) Transmit Fault Fault Here | | +----------------------+ | +----------------------+ Rx| LCCE |Egress| | Peer LCCE | ----->| |------X->| | | L2TPv3 | | L2TPv3 | Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | <-----| |<--------| | McGill & Pignataro Expires July 4, 2008 [Page 5] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 +----------------------+ +----------------------+ A fault has occurred in the transmit direction between the local endpoint and the remote L2TP endpoint. Note that a fault at the session level would not necessarily trigger a L2TP control channel timeout. The means of detecting this fault are outside the scope of this document; as an example, detection may be via BFD. (S), Pseudowire is in standby mode Standby | | +----------------------+ | +----------------------+ Rx| LCCE |Egress | Peer LCCE | ----->| |---X---->| | | L2TPv3 | | L2TPv3 | Tx| Circuit Pseudowire |Ingress | Pseudowire Circuit | <-----| |<--X-----| | +----------------------+ | +----------------------+ | | Standby The pseudowire has been placed into a standby mode which means that although it can be signalled and is operational, it is NOT switching traffic. Any received traffic SHOULD be dropped. Traffic MUST NOT be transmitted. 3. Clarifications The following are clarifications regarding the usage of these new bits: (*) If multiple faults occur, they MUST be bitwise-OR-d together. (*) The (A) bit MUST NOT be set until all fault flags are cleared. This behavior allows an endpoint to be backwards compatible with a remote endpoint that does not understand these new status bits. (*) [RFC3931] defined the (A) bit as pertaining to local access circuit state only. This draft redefines it as meaning that "no faults are present on the local pseudowire endpoint." (*) If any of the (R), (T), (I) or (E) bits are set, then the (A) bit McGill & Pignataro Expires July 4, 2008 [Page 6] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 MUST be cleared. That is, (R, T, I, E) are a more granular definition of (A), such that OR-ing the bits provides an inverted (A). (*) If (A) is clear and (R, T, I, E) are clear, it means that there is no extended circuit status. (*) The (S) bit can be set in conjunction with any other bit, including (A). i.e. an access circuit may be experiencing a fault or be active and also be in standby. (*) Leaving standby mode is indicated by the clearing of the (S) bit. (*) The (N) bit has been deprecated. 4. Security Considerations No additional security considerations exist with extending this attribute. 5. IANA Considerations All values provide above are tentative prior to adoption by IANA. 6. Acknowledgements The author wishes to thank Carlos Pignataro, Muhammad Yousuf, Mark Townsley and George Wilkie for comments received. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC4591] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4591, August 2006. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. McGill & Pignataro Expires July 4, 2008 [Page 7] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [I-D.muley-dutta-pwe3-redundancy-bit] Muley, P., Bocci, M., Newton, J., and L. Martini, "Preferential Forwarding Status bit definition", draft-muley-dutta-pwe3-redundancy-bit-02 (work in progress), November 2007. Authors' Addresses Neil McGill Cisco Systems 7025-4 Kit Creek Rd PO Box 14987 Research Triangle Park, NC 27709 USA Email: nmcgill@cisco.com Carlos Pignataro (editor) Cisco Systems 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA Phone: +1-919-392-7428 Fax: +1-919-869-1438 Email: cpignata@cisco.com McGill & Pignataro Expires July 4, 2008 [Page 8] Internet-Draft L2TPv3 Extended Circuit Status Values Jan 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). McGill & Pignataro Expires July 4, 2008 [Page 9]