[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-l2tpext-circuit-status-extensions

Network Working Group                                          N. McGill
Internet-Draft                                              C. Pignataro
Updates: 3931 (if approved)                                Cisco Systems
Intended status: Standards Track                           June 23, 2008
Expires: December 25, 2008


                 L2TPv3 Extended Circuit Status Values
           draft-nmcgill-l2tpext-circuit-status-extensions-01

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 December 25, 2008.

Abstract

   This document defines additional Layer 2 Tunneling Protocol Version 3
   (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.  It also deprecates the use of the New bit
   in the "Circuit Status" AVP, updating RFC3931.









McGill & Pignataro      Expires December 25, 2008               [Page 1]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  3
   2.  L2TPv3 Extended Circuit Status Values  . . . . . . . . . . . .  3
   3.  Circuit Status Usage and Clarifications  . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10





































McGill & Pignataro      Expires December 25, 2008               [Page 2]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 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 and used in the
   pseudowire control protocol using LDP, see [RFC4446] and [RFC4447].

   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 using LDP, see
   [I-D.ietf-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.  L2TPv3 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 circuit to which the session is bound.

   The Attribute Value field for this AVP currently defined in [RFC3931]
   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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Bit  Bit-Value   Name
     ----------------------------------------------------------------
     (A)  15  0x0001  Active
     (N)  14  0x0002  New

   Where, the A (Active) bit indicates whether the circuit is up/active/
   ready (1) or down/inactive/not-ready (0).



McGill & Pignataro      Expires December 25, 2008               [Page 3]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


   The N (New) bit indicates if the notification is for a new circuit
   (1) ir an existing circuit (0), and is provided to emulate (Frame
   Relay) NNI signaling between PEs.  It MAY be used to convey that a
   circuit has been reprovisioned or newly provisioned at the PE, which
   can already be inferred from the L2TP control message type.  It is
   uncertain as to what use the receiving PE can make of this bit,
   although it MAY include logging.  This document deprecates 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 OCRQ, OCRP) and clearing in all
   other control messages.

   This document extends this bitmap of values to allow for finer
   granularity of local pseudowire (i.e., access circuit or PSN-facing
   endpoint) status reporting.

   The Attribute Value field for the Circuit Status AVP including the
   new values has the following format:

      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)  15  0x0001  Active: Pseudowire has no faults
     (R)  14  0x0004  Local Attachment Circuit (ingress) Receive Fault
     (T)  13  0x0008  Local Attachment Circuit (egress) Transmit Fault
     (I)  12  0x0010  Local PSN-facing PW (ingress) Receive Fault
     (E)  11  0x0020  Local PSN-facing PW (egress) Transmit Fault
     (S)   9  0x0040  Pseudowire is in Standby mode

   The new bits values have the following meanings:














McGill & Pignataro      Expires December 25, 2008               [Page 4]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


   (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.

   (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






McGill & Pignataro      Expires December 25, 2008               [Page 5]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


      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 an L2TP control connection timeout.  The means of
      detecting this fault are outside the scope of this document; as an
      example, detection may be via PW Type-specific means, BFD, or
      other methods.

   (E), Local PSN-facing PW (egress) Transmit Fault

                                      Fault Here
                                           |
                                           |
             +----------------------+      |  +----------------------+
           Rx|         LCCE         |Egress|  |       Peer LCCE      |
       ----->|                      |------X->|                      |
             |             L2TPv3   |         |   L2TPv3             |
           Tx| Circuit   Pseudowire |Ingress  | Pseudowire   Circuit |
       <-----|                      |<--------|                      |
             +----------------------+         +----------------------+

      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 an L2TP control connection timeout.  The means of
      detecting this fault are outside the scope of this document; as an
      example, detection may be via PW Type-specific means, BFD, or
      other methods.

   (S), Pseudowire is in Standby mode

                                      Standby
                                        |
                                        |
             +----------------------+   |     +----------------------+
           Rx|         LCCE         |Egress   |       Peer LCCE      |
       ----->|                      |---X---->|                      |
             |             L2TPv3   |         |   L2TPv3             |
           Tx| Circuit   Pseudowire |Ingress  | Pseudowire   Circuit |
       <-----|                      |<--X-----|                      |
             +----------------------+   |     +----------------------+
                                        |
                                        |
                                      Standby





McGill & Pignataro      Expires December 25, 2008               [Page 6]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


      The pseudowire has been placed into a standby mode which means
      that although it can be signaled and is operational, it is NOT
      switching traffic.  Any received traffic SHOULD be dropped.
      Traffic MUST NOT be transmitted.


3.  Circuit Status Usage and Clarifications

   The following are clarifications regarding the usage of the Circuit
   Status AVP bits:

   o  If multiple faults occur, all the bits corresponding to each fault
      MUST be set (i.e., they MUST be bitwise-OR-d together).

   o  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.

   o  [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."

   o  If any of the (R), (T), (I) or (E) bits are set, then the (A) bit
      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).

   o  If (A) is clear and (R, T, I, E) are clear, it means that there is
      no extended circuit status.  That is, the circuit is down/
      inactive/not-ready (from the (A) bit), without a more granular
      (extended) indication.

   o  The (S) bit can be set in conjunction with any other bit,
      including (A).  A pseudowire endpoint in Standby (S bit set) can
      be up/active/ready (A bit set) or experiencing a fault (A bit
      cleared and (R, T, I, E) bit(s) set).

   o  Leaving standby mode is indicated by the clearing of the (S) bit.

   o  The (N) bit has been deprecated.


4.  Security Considerations

   No additional security considerations exist with extending this
   attribute.





McGill & Pignataro      Expires December 25, 2008               [Page 7]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


5.  IANA Considerations

   The Circuit Status Bits number space reachable at
   [IANA.l2tp-parameters] is managed by IANA as per [RFC3931].  Five new
   bits and one updated bit are requested to be assigned as follows:

   Circuit Status Bits - per [RFC3931]
   -------------------

   Bit  9 - S (Standby) bit
   Bit 10 - E (Local PSN-facing PW (egress) Tx Fault) bit
   Bit 11 - I (Local PSN-facing PW (ingress) Rx Fault) bit
   Bit 12 - T (Local AC (egress) Tx Fault) bit
   Bit 13 - R (Local AC (ingress) Rx Fault) bit
   Bit 14 - N (New) bit [use deprecated]


6.  Acknowledgements

   The authors wish to thank 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.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

7.2.  Informative References

   [I-D.ietf-pwe3-redundancy-bit]
              Muley, P., Aissaoui, M., Bocci, M., Dutta, P., and M.
              Lasserre, "Preferential Forwarding Status bit definition",
              draft-ietf-pwe3-redundancy-bit-00 (work in progress),
              February 2008.

   [IANA.l2tp-parameters]
              Internet Assigned Numbers Authority, "Layer Two Tunneling
              Protocol "L2TP"", December 2007,
              <http://www.iana.org/assignments/l2tp-parameters>.

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.



McGill & Pignataro      Expires December 25, 2008               [Page 8]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 2008


   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [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.


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
   Cisco Systems
   7200-12 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709
   USA

   Email: cpignata@cisco.com






















McGill & Pignataro      Expires December 25, 2008               [Page 9]


Internet-Draft    L2TPv3 Extended Circuit Status Values        June 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.











McGill & Pignataro      Expires December 25, 2008              [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/