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

Versions: (draft-nmcgill-l2tpext-circuit-status-extensions) 00 01 02 03 04 05 RFC 5641

Network Working Group                                          N. McGill
Internet-Draft                                              C. Pignataro
Updates: 3931, 4349, 4454, 4591,                           Cisco Systems
4719 (if approved)                                         July 12, 2009
Intended status: Standards Track
Expires: January 13, 2010


                 L2TPv3 Extended Circuit Status Values
            draft-ietf-l2tpext-circuit-status-extensions-05

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 13, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document defines additional Layer 2 Tunneling Protocol Version 3



McGill & Pignataro      Expires January 13, 2010                [Page 1]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


   (L2TPv3) bit values to be used within the "Circuit Status" Attribute
   Value Pair (AVP) to communicate finer-grained error states for
   Attachment Circuits (ACs) and Pseudowires (PWs).  It also generalizes
   the Active bit and deprecates the use of the New bit in the "Circuit
   Status" AVP, updating RFC3931, RFC4349, RFC4454, RFC4591, and
   RFC4719.


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  . . . . . . . . . . .  8
   4.  Updates to Existing RFCs . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11





























McGill & Pignataro      Expires January 13, 2010                [Page 2]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


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 the Label Distribution Protocol
   (LDP), see Section 3.5 of [RFC4446] and Section 5.4.2 of [RFC4447].

   Additionally, it is useful (in session-level redundancy scenarios) to
   be able to indicate if a pseudowire is in a standby state, where it
   is fully established by signaling and allows OAM, but is not
   switching data.  Again, such functionality is available for MPLS-
   based pseudowires using LDP, see [I-D.ietf-pwe3-redundancy-bit].

   This document provides extended circuit status bit values for L2TPv3
   and adds 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 that use the Circuit Status AVP.

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

   As currently defined in [RFC3931] and replicated in [RFC4349],



McGill & Pignataro      Expires January 13, 2010                [Page 3]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


   [RFC4454], [RFC4591], and [RFC4719], the two bits have the following
   meanings:

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

   o  The N (New) bit indicates whether the circuit status indication is
      for a new circuit (1) or an existing circuit (0).

   This document updates the semantics of the A and N bits as follows
   (see also Section 4):

   The A (Active) bit indicates whether the local pseudowire endpoint
   (both local Attachment Circuit (AC) and local Packet Switched Network
   (PSN) facing pseudowire) has no faults present and is up/active/ready
   (1) or has faults present and is down/inactive/not-ready (0).

   The N (New) bit indicates if the notification is for a new circuit
   (1) or an existing circuit (0), and is provided to emulate (Frame
   Relay) NNI signaling between Provider Edge (PE) routers.  It MAY be
   used to convey that a circuit has been re-provisioned or newly
   provisioned at the PE, which can already be inferred from the L2TP
   control message type.  It is therefore 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 set on
   sending.  For reference, see Section 3.4 of [RFC4591] which does not
   specify any additional usage beyond the setting of the N bit in the
   ICRQ, ICRP (and OCRQ, OCRP) and clearing in all other control
   messages.

   This document also 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:














McGill & Pignataro      Expires January 13, 2010                [Page 4]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Reserved    |S|E|I|T|R|N|A|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Bit  Bit-Value   Name
     -----------------------------------------------------------------
     (A)  15  0x0001  Active: Pseudowire has no faults
     (N)  14  0x0002  New [use deprecated]
     (R)  13  0x0004  Local Attachment Circuit (ingress) Receive Fault
     (T)  12  0x0008  Local Attachment Circuit (egress) Transmit Fault
     (I)  11  0x0010  Local PSN-facing PW (ingress) Receive Fault
     (E)  10  0x0020  Local PSN-facing PW (egress) Transmit Fault
     (S)   9  0x0040  Pseudowire is in Standby mode

   The new bits values have the following meanings:

   (R), Local Attachment Circuit (ingress) Receive Fault

    Fault Here
         |
         |
         |   +----------------------+         +----------------------+
         | Rx|         LCCE         |Egress   |       Peer LCCE      |
       --X-->|                      |-------->|                      |
             |             L2TPv3   |  [PSN]  |   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 January 13, 2010                [Page 5]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


   (T), Local Attachment Circuit (egress) Transmit Fault

             +----------------------+         +----------------------+
           Rx|         LCCE         |Egress   |       Peer LCCE      |
       ----->|                      |-------->|                      |
             |             L2TPv3   |  [PSN]  |   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   |  [PSN]  |   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 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,
      Bidirectional Forwarding Detection (BFD), or other methods.














McGill & Pignataro      Expires January 13, 2010                [Page 6]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


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

                                      Fault Here
                                           |
                                           |
             +----------------------+      |  +----------------------+
           Rx|         LCCE         |Egress|  |       Peer LCCE      |
       ----->|                      |------X->|                      |
             |             L2TPv3   |  [PSN]  |   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   |  [PSN]  |   L2TPv3             |
           Tx| Circuit   Pseudowire |Ingress  | Pseudowire   Circuit |
       <-----|                      |<--X-----|                      |
             +----------------------+   |     +----------------------+
                                        |
                                        |
                                      Standby

      The pseudowire has been placed into a standby mode which means
      that although it was signaled (setup of the PW) and is
      operational, it is NOT switching user traffic.  Any received user
      traffic SHOULD be dropped.  User traffic MUST NOT be transmitted.

      A standby pseudowire also allows for means to check its data plane
      liveness, to ensure its ability to switch data packets end-to-end.
      This is achieved for example as detailed in [RFC5085] or
      [I-D.ietf-pwe3-vccv-bfd].  However, data is not forwarded from an
      Access Circuit (AC) into the L2TPv3 session, or from the L2TPv3



McGill & Pignataro      Expires January 13, 2010                [Page 7]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


      session out of the AC.


3.  Circuit Status Usage and Clarifications

   In implementations prior to this specification, bits 0-13 MUST be set
   to zero (see Section 5.4.5 of [RFC3931]).  This allows for legacy
   implementations to interwork properly with new implementations.

   The following are clarifications regarding the usage of the Circuit
   Status AVP bits as defined in this specification:

   o  The (R), (T), (I) and (E) bits are collectively referred to as
      "fault 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 multiple faults occur, all the fault status 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 status bits are
      cleared.  This behavior allows an endpoint to be backwards
      compatible with a remote endpoint that does not understand these
      new status bits.

   o  If any of the fault status bits are set, then the (A) bit MUST be
      cleared.  That is, the fault status bits (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 the fault status bits (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 usage of the (N) bit has been deprecated.





McGill & Pignataro      Expires January 13, 2010                [Page 8]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


4.  Updates to Existing RFCs

   This document updates existing RFCs that define (either generically
   or in the context of a specific set of PW Types) the Active and New
   bits of the Circuit Status AVP.  The Active and New bits of the
   Circuit Status AVP are specified in Section 5.4.5 of [RFC3931].
   Those definitions are adapted to specific Attachment Circuits and
   replicated in Section 3.4 of [RFC4349] (HDLC Frames over L2TPv3),
   Section 8 of [RFC4454] (ATM over L2TPv3), Section 3.4 of [RFC4591]
   (Frame Relay over L2TPv3), and Section 2.3.3 of [RFC4719] (Ethernet
   Frames over L2TPv3).  This document updates the definitions in all
   these five references to say:

      The A (Active) bit indicates whether the local pseudowire endpoint
      (both local attachment circuit and local PSN-facing pseudowire)
      has no faults present and is up/active/ready (1) or has faults
      present and is down/inactive/not-ready (0).

      The N (New) bit usage is deprecated, it SHOULD be ignored on
      receipt and is OPTIONAL to set on sending.

   This document also updates Section 2.2 (bullet c) of [RFC4719],
   removing the following two sentences:

      For ICRQ and ICRP, the Circuit Status AVP MUST indicate that the
      circuit status is for a new circuit (refer to N bit in Section
      2.3.3).

      For ICCN and SLI (refer to Section 2.3.2), the Circuit Status AVP
      MUST indicate that the circuit status is for an existing circuit
      (refer to N bit in Section 2.3.3) and reflect the current status
      of the link (refer to A bit in Section 2.3.3).

   And finally, updates Section 3.1 of [RFC4349], Section 3.1 of
   [RFC4454], Section 3.1 of [RFC4591], and Section 2.2 of [RFC4719]
   with the following paragraph addition:

      The usage of the N bit in the Circuit Status AVP is deprecated.
      Therefore, for ICRQ and ICRP the Circuit Status AVP need not
      indicate on sending (nor check on receipt) that the circuit status
      is for a new circuit, and for ICCN and SLI the Circuit Status AVP
      need not indicate on sending (nor check on receipt) that the
      circuit status is for an existing circuit.








McGill & Pignataro      Expires January 13, 2010                [Page 9]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


5.  Security Considerations

   Security considerations for the Circuit Status AVP are covered in the
   base L2TPv3 specitication (see Section 8 of [RFC3931]).  No
   additional security considerations exist with extending this
   attribute.


6.  IANA Considerations

   The Circuit Status Bits number space reachable at
   [IANA.l2tp-parameters] is managed by IANA as per Section 10.7 of
   [RFC3931].  Five new bits (bits 9 through 13) and one updated bit
   (bit 14) 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]


7.  Acknowledgements

   The authors wish to thank Muhammad Yousuf, Mark Townsley, George
   Wilkie, Prashant Jhingran, Pawel Sowinski, and Ignacio Goyret for
   useful comments received.


8.  References

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

   [RFC4349]  Pignataro, C. and M. Townsley, "High-Level Data Link
              Control (HDLC) Frames over Layer 2 Tunneling Protocol,
              Version 3 (L2TPv3)", RFC 4349, February 2006.

   [RFC4454]  Singh, S., Townsley, M., and C. Pignataro, "Asynchronous



McGill & Pignataro      Expires January 13, 2010               [Page 10]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


              Transfer Mode (ATM) over Layer 2 Tunneling Protocol
              Version 3 (L2TPv3)", RFC 4454, May 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.

   [RFC4719]  Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport
              of Ethernet Frames over Layer 2 Tunneling Protocol Version
              3 (L2TPv3)", RFC 4719, November 2006.

8.2.  Informative References

   [I-D.ietf-pwe3-redundancy-bit]
              Muley, P., Bocci, M., and L. Martini, "Preferential
              Forwarding Status bit definition",
              draft-ietf-pwe3-redundancy-bit-01 (work in progress),
              September 2008.

   [I-D.ietf-pwe3-vccv-bfd]
              Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
              Detection (BFD) for the Pseudowire Virtual Circuit
              Connectivity Verification (VCCV)",
              draft-ietf-pwe3-vccv-bfd-05 (work in progress), June 2009.

   [IANA.l2tp-parameters]
              Internet Assigned Numbers Authority, "Layer Two Tunneling
              Protocol "L2TP"", March 2009,
              <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.

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

   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
              Connectivity Verification (VCCV): A Control Channel for
              Pseudowires", RFC 5085, December 2007.











McGill & Pignataro      Expires January 13, 2010               [Page 11]

Internet-Draft    L2TPv3 Extended Circuit Status Values        July 2009


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 January 13, 2010               [Page 12]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/