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

Versions: (draft-martini-pwe3-static-pw-status) 00 01 02 03 04 05 06 07 08 09 10 RFC 6478

Internet Engineering Task Force                             Luca Martini
Internet Draft                                            George Swallow
Intended status: Standards Track                             Giles Heron
Expires: September 14, 2011                                        Cisco

                                                           Matthew Bocci
                                                          Alcatel-Lucent

                                                          March 14, 2011


                Pseudowire Status for Static Pseudowires


                draft-ietf-pwe3-static-pw-status-03.txt

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 September 14, 2010

Abstract

   This document specifies a mechanism to signal Pseudowire (PW) status
   messages using an PW associated channel (ACh). Such a mechanism is
   suitable for use where no PW dynamic control plane exits, known as
   static PWs, or where a Terminating Provider Edge (T-PE) needs to send
   a PW status message directly to a far end T-PE. The mechanism allows
   PW OAM message mapping and PW redundancy to operate on static PWs.




Martini, et al.                                                 [Page 1]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011




Table of Contents

    1        Specification of Requirements  ........................   2
    2        Introduction  .........................................   3
    3        Terminology  ..........................................   3
    4        Applicability  ........................................   3
    5        Pseudowire Status Operation  ..........................   4
    5.1      PW OAM Message  .......................................   4
    5.2      Sending a PW Status Message  ..........................   5
    5.3      PW OAM status message transmit and receive  ...........   5
    5.3.1    Acknowledgement of PW status  .........................   6
    5.3.2    Applicable PW status Bits  ............................   7
    5.4      MPLS Label Stack  .....................................   7
    5.4.1    Label stack for a message destined to the next PE  ....   7
    5.4.2    Label stack for a message destined to the egress PE  ..   7
    5.5      S-PE bypass mode  .....................................   8
    5.5.1    S-PE bypass mode LDP flag bit  ........................   8
    5.5.2    S-PE bypass mode negotiation procedure  ...............   9
    6        S-PE operation  .......................................   9
    6.1      Static PW to another Static PW  .......................   9
    6.2      Dynamic PW to Static PW or vice versa  ................  10
    7        Security Considerations  ..............................  10
    8        IANA Considerations  ..................................  10
    9        References  ...........................................  11
    9.1      Normative References  .................................  11
    9.2      Informative References  ...............................  11
   10        Authors' Addresses  ...................................  11





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












Martini, et al.                                                 [Page 2]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


2. Introduction

   The default control plane for Pseudowire (PW) technology, as defined
   in [RFC4447], is based on LDP. However that document also describes a
   static provisioning mode without control plane. When a static PW is
   used, there is no method to transmit the status of the PW, or
   attachment circuit (AC) between the two PEs at each end of the PW.
   This document defines a method to transport the PW status codes
   defined in [RFC4447], sec 5.4.2, and [REDUNDANCY] in-band with the PW
   data using a generic associated channel [RFC5586].


3. Terminology

   FEC: Forwarding Equivalence Class

   LDP: Label Distribution Protocol

   LSP: Label Switching Path

   MS-PW: Multi-Segment Pseudowire

   PE: Provider Edge

   PW: Pseudowire

   SS-PW: Single-Segment Pseudowire

   S-PE: Switching Provider Edge Node of MS-PW

   T-PE: Terminating Provider Edge Node of MS-PW


4. Applicability

   The procedures described in this draft are intended for the case
   where PWs are statically configured. Where an LDP control plane
   exists, this MUST be used for signaling all PW status messages with
   the exception of those specified in [REDUNDANCY]. For [REDUNDANCY],
   the 'S-PE' bypass mode described below MAY be used in the presence of
   an LDP control plane.










Martini, et al.                                                 [Page 3]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


5. Pseudowire Status Operation

5.1. PW OAM Message

   The PW status TLV as defined in [RFC4447] sec 5.4.2 is transported in
   a PW OAM message using the PW associated channel (ACH).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    | 0xZZ PW OAM Message           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Refresh Timer         |  TLV Length   |A|   Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            TLVs                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 1: ACH PW OAM Message Packet Header.


   The first 32 bits are the standard ACH header construct as defined in
   [RFC5586].

   The first nibble (0001b) indicates the ACH instead of PW data. The
   version and the reserved values are both set to 0 as specified in
   [RFC4385].

   The refresh timer is an unsigned integer and specifies refresh time
   in seconds with a range from 1 to 65535. The value 0 means that the
   refresh timer is set indefinitely, and the PW OAM message will never
   be refreshed, and will never timeout. This mode SHOULD NOT be used
   other then when specified in this document.

   The TLV length field indicates the length of all PW OAM TLVs only.

   The A flag bit is used to indicate an acknowledgment of the PW status
   TLV included. The rest of the flag bits are reserved and they must be
   set to 0 on transmit, and ignored upon receive. When the A bit is
   set, the refresh timer value is a requested timer value. PW OAM
   Message code point = 0xZZ.  [ZZ to be assigned by IANA from the PW
   Associated Channel Type registry.]

   TLV types for use in this message are allocated by IANA in the LDP
   registry named: "TLV TYPE NAME SPACE" .






Martini, et al.                                                 [Page 4]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


5.2. Sending a PW Status Message

   PW Status messages are indicated by sending in-band PW OAM messages
   for a particular PW containing the PW Status TLV defined in
   [RFC4447].  The PW Status TLV format is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res|     PW Status (0x096A)    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Status Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 2: PW Status Message Format.


   The first 2 bits are reserved, and MUST be set to zero on transmit,
   and ignored on receive.

   The PW Status TLV is prepended with an PW OAM message header and sent
   on the ACH of the PW to which the status update applies.

   To clear a particular status indication, the PE needs to send a new
   PW OAM message containing a PW Status TLV with the corresponding bit
   cleared.

   The procedures described in [RFC6073] that apply to an S-PE and PW
   using an LDP control plane also apply when sending PW status using
   the PW OAM channel. The OPTIONAL procedures using the S-PE TLV
   described in [RFC6073] can also be applied when sending PW status
   using the PW OAM channel.

   The detailed message transmit, and receive procedures are specified
   in the next section. PW OAM Status Messages MUST NOT be used as a
   connectivity verification method.


5.3. PW OAM status message transmit and receive

   Unlike the PW status procedures defined in [RFC4447] with this method
   there is no TCP/IP session, or session management. Therefore unlike
   the TCP/IP case, where each message is sent only once, the PW OAM
   message containing the PW status TLV needs to be transmitted
   repeatedly to ensure reliable message delivery.

   The PW OAM message containing a PW status TLV with a new status bit
   set, will be transmitted twice at an initial interval of one second.
   Subsequently the PW OAM message will be transmitted with an interval



Martini, et al.                                                 [Page 5]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


   specified by the refresh timer value in the packet. Note that this
   value MAY be updated in the new PW OAM message packet, in which case
   the new refresh timer value becomes the new packet transmit interval.

   The suggested default value for the refresh timer is 30 seconds.

   When a PW OAM message containing a status TLV is received, a timer is
   started according to the refresh rate specified in the packet. If
   another non zero PW status message is not received within 3.5 times
   the specified timer value, the status condition will timeout in 3.5
   times the last refresh timer value received, and the default status
   of zero is assumed on the PW. It is also a good practice to introduce
   some jitter in the delay between refresh transmissions, as long as
   the maximum jitter delay is within the prescribed maximum refresh
   time of 3.5 times the specified timer value for 3 consecutive refresh
   packets.

   To clear a particular status fault the PE need only send an updated
   message with the corresponding bit cleared. If the PW status code is
   zero, the PW OAM message will be sent using the method described
   above, however it MUST be acknowledged with a packet with a timer
   value of zero. This will cause the PE sending the message to stop
   sending, and to continue normal operation.

   The message containing the clear status TLV is sent according to the
   same rules defined above.


5.3.1. Acknowledgement of PW status

   The PE receiving a PW OAM message containing a PW status message can
   acknowledge the PW status message by simply building an almost
   identical reply packet with the A bit set, and transmitting it on the
   PW ACH back to the source of the PW status message. The timer value
   set in the reply packet will then be used as the new transmit
   interval. If the sender PE of a PW status message receives an
   acknowledgement for a particular message where the PW status TLV
   matches exactly the PW status TLV in the message that is currently
   being refreshed, the sender PE MUST use the new timer value received.

   The suggested default value for the refresh timer value in the
   acknowledgement packet is 600 seconds.

   If the sender PE receives an acknowledgement message that does not
   match the current active PW status message being sent, it simply
   ignores the acknowledgment packet.

   If a PE that has a non zero status code for a particular PW, detects



Martini, et al.                                                 [Page 6]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


   by any means that the peer PE has become unreachable, it will follow
   the standard procedures and consider that PW as having an additional
   status bit set. This would normally trigger sending updates again,
   and canceling the acknowledgement refresh timer state.


5.3.2. Applicable PW status Bits

   In some situations it might not be useful or possible to transit a PW
   status message because the remote PE is not reachable. For example a
   PE that detects a local PSN TX fault condition, will be unable to
   transmit a PW OAM message with a PW status TLV reflecting that
   condition. The general rule is that a PE or S-PE should always
   attempt to send a PW status message.


5.4. MPLS Label Stack

   With one exception, all PW OAM status messages are are sent to the
   adjacent PE across the PSN tunnel. in many cases the transmitting PE
   has no way to determine whether the adjacent PE is a S-PE, or a T-PE.
   This is a necessary behavior to preserve backward compatibility with
   PEs that do not understand MS-PWs. In the procedures described in
   this document there are two possible destinations for the PW OAM
   status messages: the adjacent PE, or the T-PE. Sending a PW status
   message directly to the T-PE is a enhanced method that is only
   applicable using PW OAM status messages sent in the PW ACH.


5.4.1. Label stack for a message destined to the next PE

   A PE that needs to forward a PW OAM status message to the adjacent PE
   across the PSN tunnel, MUST set the PW label TTL field to 1.
   Furthermore if the control word is not in use on the particular PW,
   the PE MUST also place the GAL reserved label [RFC5586], below the PW
   label also with the TTL field set to 1.


5.4.2. Label stack for a message destined to the egress PE

   This is also known as "S-PE bypass mode" see below. A T-PE that
   requires sending a PW OAM status message directly to the
   corresponding T-PE at the other end of the PW MUST set the TTL of the
   PW label to a value that is sufficient to reach the corresponding T-
   PE. This value will be greater then one, but will be set according to
   the local policy on the transmitting T-PE. Furthermore if the control
   word is not in use on the particular PW, the PE MUST also place the
   GAL reserved label [RFC5586], below the PW label with the TTL field



Martini, et al.                                                 [Page 7]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


   set to 1.



5.5. S-PE bypass mode

   S-PE bypass mode enables a T-PE to bypass all S-PEs that might be
   present along the MS-PW and to send a message directly to the remote
   T-PE. This is used for very fast message transmission in-band with
   the PW PDUs. This mode is OPTIONAL, and must be supported by both T-
   PEs to be enabled.

   Note that this method MUST NOT be used to send messages which are
   permitted to originate at an S-PE, since otherwise race conditions
   could occur between messages sent via the control plane by S-PEs, and
   messages sent via the data plane by T-PEs.

   Currently the only PW status codes which MAY be sent using the S-PE
   bypass procedure are:

   0x00000002 - Local Attachment Circuit (ingress) Receive Fault
   0x00000004 - Local Attachment Circuit (egress) Transmit Fault

   Note that since "clear all failures" may be sent by an S-PE it MUST
   NOT be sent using the S-PE bypass mode.

   When S-PE bypass mode is enabled, all PW Status TLVs received using
   this method have priority over PW Status TLVs sent via control
   protocols such as LDP [RFC4447].


5.5.1. S-PE bypass mode LDP flag bit

   When a PW Segment along an MS-PW is using the LDP control protocol, a
   flag bit MUST be set in the interface parameters sub-TLV to indicate
   that the T-PE is requesting S-PE bypass status message mode. If the
   S-PE bypass mode LDP flag bit in the generic protocol flags interface
   parameter does not mach in the FEC advertisement for directions of a
   specific PW, that PW MUST NOT be enabled.

   The interface parameter is defined as follows:










Martini, et al.                                                 [Page 8]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type=0X16  |   Length=4    |R R R R R R R R R R R R R R R B|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Generic Protocol Flags.


     - TLV Type.

       Type 0x16 - Generic Protocol Flags.  Note: Value 0x16 suggested
       for assignment pending IANA allocation.

     - Length

       TLV length always 4 octets.

     - Flags

       Protocol flags, Bit B is set to request the S-PE bypass mode.
       Bits R are reserved for future use, and must be zero on
       transmission, and ignored on reception of this TLV.


5.5.2. S-PE bypass mode negotiation procedure

   To be written in the next revision.


6. S-PE operation

   The S-PE will operate according to the procedures defined in
   [RFC6073].  The following additional procedures apply to the case
   where a static PW segment is switched to a dynamic PW segment that
   uses LDP, and the case a static PW segment is switched to another
   static PW segment.


6.1. Static PW to another Static PW

   The procedures that are described in [RFC6073] section 10 also apply
   to the case of a static PW switched to another static PW. The LDP
   header is simply replaced by the PW OAM header, otherwise the packet
   format will be identical. The information that is necessary to form a
   SP-PE TLV MUST be configured in the S-PE, or no SP-PE TLV will be
   sent.  The Document [RFC6073] defines a IANA registry named
   "Pseudowire Switching Point PE TLV Type". In order to support the



Martini, et al.                                                 [Page 9]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


   static PW configuration and addressing scheme, a new code point is
   requested as follows:

   Type  Length   Description
   0x07      24   Static PW/MPLS-TP PW segment ID of last
                  PW segment traversed


   The format of this TLV is that of the "Static Pseudowire Sub-TLV"
   defined in [ON DEMAND].


6.2. Dynamic PW to Static PW or vice versa

   The procedures that are described in [RFC6073] section 10 also apply
   to this situation. However if the PW label of the LDP controlled PW
   segment is withdrawn, by the adjacent PE, the S-PE will set the PW
   status code "0x00000001 - Pseudowire Not Forwarding" to the adjacent
   PW on the static PW segment.

   The S-PE will only withdraw its label for the dynamic, LDP
   controlled, PW segment if the S-PE is un-provisioned.


7. Security Considerations

   The security measures described in [RFC4447] and [RFC6073] are
   adequate for the proposed mechanism.


8. IANA Considerations

   This document uses a new Associated Channel Type. IANA already
   maintains a registry of name "Pseudowire Associated Channel Types". A
   value of 0x0022 is suggested for assignment with TLVs. The
   description is "PW OAM Message".

   This document uses a new Pseudowire Switching Point PE TLV Type. IANA
   already maintains a registry of name "Pseudowire Switching Point PE
   TLV Type". A value of 0x07 is suggested for assignment. The
   description is "Static PW/MPLS-TP PW segment ID of last PW segment
   traversed".

   This document uses a new interface parameter type. IANA already
   maintains a registry of name "Pseudowire Interface Parameters Sub-TLV
   type Registry". A value of 0x16 is suggested for assignment. The
   description is "Generic Protocol Flags".




Martini, et al.                                                [Page 10]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011


9. References

9.1. Normative References

   [RFC2119]   Bradner. S, "Key words for use in RFCs to
        Indicate Requirement Levels", RFC 2119, March, 1997.

   [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
        et al., rfc4447 April 2006.

   [RFC6073] Martini et.al. "Segmented Pseudowire",
        RFC 6073, January 2011.

   [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3)
        Control Word for Use over an MPLS PSN", S. Bryant, et al.,
        RFC4385, February 2006.

   [REDUNDANCY] Muley et.al. "Preferential Forwarding Status
         bit definition", draft-ietf-pwe3-redundancy-bit-03.txt,
        IETF Work in Progress, May 2010.

   [ON DEMAND] Bahadur et.al. "MPLS on-demand Connectivity
        Verification, Route Tracing and Adjacency Verification",
        draft-ietf-mpls-tp-on-demand-cv-02.txt, IETF Work in Progress,
        October 2010


9.2. Informative References

   [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.,
        "MPLS Generic Associated Channel", rfc5586,  June 2009


10. Authors' Addresses


   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: lmartini@cisco.com










Martini, et al.                                                [Page 11]

Internet Draft  draft-ietf-pwe3-static-pw-status-03.txt   March 14, 2011



   George Swallow
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, Massachusetts  01719
   United States
   e-mail: swallow@cisco.com


   Giles Heron
   Cisco Systems
   9-11 New Square
   Bedfont Lakes
   Feltham
   Middlesex
   TW14 8HA
   United Kingdom
   e-mail: giheron@cisco.com


   Matthew Bocci
   Alcatel-Lucent
   Grove House, Waltham Road Rd
   White Waltham, Berks, UK. SL6 3TN
   e-mail: matthew.bocci@alcatel-lucent.co.uk


Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   Expiration Date: September 2011








Martini, et al.                                                [Page 12]


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