Subject: [PWE3] ietf secretariat posting issues - draft-martini-pwe3-iccp-00.txt

From: Luca Martini <[email-masked]>
Date: Wed, 23 Jul 2008 11:36:23 -0600

I have been using the [email-masked] mailing address , and the 
secretariat dropped the e-mail message.
So I will post here the documents that did not get posted , but we need 
to discuss in the meeting in Dublin.

Sorry for the mishap.

Luca

,Au Nadeau "Thomas D. Nadeau" "BT"
PWE3 Working Group                                          Luca Martini
Internet Draft                                                     Cisco
Expires: December 2008                                       Samer Salam
                                                                   Cisco
Satoru Matsushima                                            Ali Sajassi
Softbank                                                          Cisco

                                                               June 2008

      Inter-Chassis Communication Protocol for L2VPN PE Redundancy

                     draft-martini-pwe3-iccp-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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document specifies an inter-chassis communication protocol
   (ICCP) that enables PE redundancy for Virtual Private Wire Service
   (VPWS) and Virtual Private LAN Service (VPLS) applications. The
   protocol runs within a set of two or more PEs, forming a redundancy
   group, for the purpose of synchronizing data amongst the systems. It
   accommodates multi-chassis attachment circuit as well as pseudowire
   redundancy mechanisms.

Martini, et al.                                                 [Page 1]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

Table of Contents

    1        Specification of Requirements  ........................   3
    2        Acknowledgments  ......................................   3
    3        Introduction  .........................................   3
    4        ICCP Overview  ........................................   4
    4.1      Redundancy Model & Topology  ..........................   4
    4.2      ICCP Interconnect Scenarios  ..........................   5
    4.2.1    Co-located Dedicated Interconnect  ....................   5
    4.2.2    Co-located Shared Interconnect  .......................   6
    4.2.3    Geo-redundant Dedicated Interconnect  .................   7
    4.2.4    Geo-redundant Shared Interconnect  ....................   8
    4.3      ICCP Requirements  ....................................   9
    5        ICC LDP Protocol extension Specification  .............  10
    5.1      LDP ICC capability advertisement  .....................  11
    5.2      RG Membership Management  .............................  11
    5.3      Application Connection Management  ....................  12
    5.4      Application Data Transfer  ............................  12
    6        ICCP PE Node Failure Detection Mechanism  .............  13
    7        ICCP Message Formats  .................................  14
    7.1      Encoding ICC into LDP messages   ......................  14
    7.1.1    ICC Header  ...........................................  14
    7.1.2    Message Encoding  .....................................  16
    7.2      RG Connect Message  ...................................  17
    7.2.1    Sender Name TLV  ......................................  18
    7.3      RG Disconnect Message  ................................  19
    7.4      RG Notification Message  ..............................  20
    7.4.1    Notification Message TLVs  ............................  21
    7.5      RG Application Data Message  ..........................  23
    7.6      Application TLVs  .....................................  24
    7.6.1    Pseudowire Redundancy (PW-RED) Application TLVs  ......  24
    7.6.1.1  PW-RED Connect TLV  ...................................  24
    7.6.1.2  PW-RED Disconnect TLV  ................................  25
    7.6.1.3  PW-RED Config TLV  ....................................  25
    7.6.1.4  Service Name TLV  .....................................  26
    7.6.1.5  PW ID TLV  ............................................  26
    7.6.1.6  Generalized PW ID TLV  ................................  27
    8        LDP Capability Negotiation  ...........................  29
    9        Client Applications  ..................................  30
    9.1      Pseudowire Redundancy Application Procedures  .........  30
    9.1.1    Initial Setup  ........................................  30
    9.1.2    Pseudowire Configuration  .............................  30
    9.1.3    Pseudowire Status Synchronization  ....................  31
    9.1.4    PE Node Failure  ......................................  31
    9.2      Attachment Circuit Redundancy Application Procedures  .  32
    9.2.1    Common AC Procedures  .................................  32

Martini, et al.                                                 [Page 2]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

    9.2.1.1  AC Failure  ...........................................  32
    9.2.1.2  PE Node Failure  ......................................  32
    9.2.1.3  PE Isolation  .........................................  32
    9.2.2    ATM AC Procedures  ....................................  32
    9.2.3    Frame Relay AC Procedures  ............................  33
    9.2.4    Ethernet AC Procedures  ...............................  33
   10        Security Considerations  ..............................  33
   11        IANA Considerations  ..................................  33
   11.1      MESSAGE TYPE NAME SPACE  ..............................  33
   11.2      TLV TYPE NAME SPACE  ..................................  33
   11.3      ICC RG Parameter Type Space  ..........................  34
   11.4      STATUS CODE NAME SPACE  ...............................  34
   12        Full Copyright Statement  .............................  35
   13        Intellectual Property Statement  ......................  35
   14        Normative References  .................................  36
   15        Informative References  ...............................  36
   16        Author Information  ...................................  36

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 RFC 2119.

2. Acknowledgments

   The authors wish to acknowledge the important contributions of Neil
   McGill and Amir Maleki.

3. Introduction

   Network availability is a critical metric for service providers as it
   has a direct bearing on their profitability. Outages translate not
   only to lost revenue but also to potential penalties mandated by
   contractual agreements with customers running mission-critical
   applications that require tight SLAs. This is true for any carrier
   network, and networks employing Layer2 Virtual Private Network
   (L2VPN) technology are no exception. Network high-availability can be
   achieved by employing intra and inter-chassis redundancy mechanisms.
   The focus of this document is on the latter. The document defines an
   Inter-Chassis Communication Protocol (ICCP) that allows
   synchronization of state and configuration data between a set of two

Martini, et al.                                                 [Page 3]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   or more PEs forming a Redundancy Group (RG). The protocol supports
   multi-chassis redundancy mechanisms that can be employed on either
   the attachment circuit or pseudowire front.

4. ICCP Overview

4.1. Redundancy Model & Topology

   The focus of this document is on PE node redundancy. It is assumed
   that a set of two or more PE nodes are designated by the operator to
   form a Redundancy Group (RG). Members of a Redundancy Group fall
   under a single administration (e.g. service provider) and employ a
   common redundancy mechanism towards the access (attachment circuits
   or access pseudowires) and/or towards the core (pseudowires) for any
   given service instance. It is possible, however, for members of an RG
   to make use of disparate redundancy mechanisms for disjoint services.
   The PE devices may be offering any type of L2VPN service, i.e. VPWS
   or VPLS. As a matter of fact, the use of ICCP may even be applicable
   for Layer 3 service redundancy, but this is considered to be outside
   the scope of this document.

   The PEs in an RG offer multi-homed connectivity to either individual
   devices (e.g. CE, DSLAM, etc...) or entire networks (e.g. access
   network). Figure 1 below depicts the model.

                                    +=================+
                                    |                 |
   Mutli-homed         +----+       |  +-----+        |
   Node  ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->|
                       |    |--+   -|--|     ||<------|---Pseudowire-->|
                       +----+  |  / |  +-----+        |
                               | /  |     ||          |
                               |/   |     || ICCP     |--> Towards Core
              +-------------+  /    |     ||          |
              |             | /|    |  +-----+        |
              |    Access   |/ +----|--| PE2 ||<------|---Pseudowire-->|
              |   Network   |-------|--|     ||<------|---Pseudowire-->|
              |             |       |  +-----+        |
              |             |       |                 |
              +-------------+       |   Redundancy    |
                ^                   |     Group       |
                |                   +=================+
                |
         Multi-homed Network

                 Figure 1: Generic Multi-chassis Redundancy Model

Martini, et al.                                                 [Page 4]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   In the topology of Figure 1, the redundancy mechanism employed
   towards the access node/network can be one of a multitude of
   technologies, e.g. it could be IEEE 802.3ad Link Aggregation Groups
   with Link Aggregation Control Protocol (LACP), or SONET APS. The
   specifics of the mechanism are out of the scope of this document.
   However, it is assumed that the PEs in the RG are required to
   communicate amongst each other in order for the access redundancy
   mechanism to operate correctly. As such, it is required to run an
   inter-chassis communication protocol among the PEs in the RG in order
   to synchronize configuration and/or running state data.

   Furthermore, the presence of the inter-chassis communication channel
   allows simplification of the pseudowire redundancy mechanism. This is
   primarily because it allows the PEs within an RG to run some
   arbitration algorithm to elect which pseudowire(s) should be in
   active or standby mode for a given service instance. The PEs can then
   advertise the outcome of the arbitration to the remote-end PE(s), as
   opposed to having to embed a hand-shake procedure into the pseudowire
   redundancy status communication mechanism, and every other possible
   Layer 2 status communication mechanism.

4.2. ICCP Interconnect Scenarios

   When referring to 'interconnect' in this section, we are concerned
   with the links or networks over which Inter-Chassis Communication
   Protocol messages are transported, and not normal data traffic
   between PEs. The PEs which are members of an RG may be either
   physically co-located or geo-redundant.  Furthermore, the physical
   interconnect between the PEs over which ICCP is to run may comprise
   of either dedicated back-to-back links or a shared connection through
   the PSN network (e.g., core). This gives rise to a matrix of four
   interconnect scenarios, described next.

4.2.1. Co-located Dedicated Interconnect

   In this scenario, the PEs within an RG are co-located in the same
   physical location (POP, CO). Furthermore, dedicated links provide the
   interconnect for ICCP among the PEs.

Martini, et al.                                                 [Page 5]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

           +=================+     +-----------------+
           |CO               |     |                 |
           |  +-----+        |     |                 |
           |  | PE1 |________|_____|                 |
           |  |     |        |     |                 |
           |  +-----+        |     |                 |
           |     ||          |     |                 |
           |     || ICCP     |     |       Core      |
           |     ||          |     |      Network    |
           |  +-----+        |     |                 |
           |  | PE2 |________|_____|                 |
           |  |     |        |     |                 |
           |  +-----+        |     |                 |
           |                 |     |                 |
           +=================+     +-----------------+

   Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario

   Given that the PEs are connected back-to-back in this case, it is
   possible to rely on Layer 2 redundancy mechanisms to guarantee the
   robustness of the links carrying the ICCP. For example, if the
   interconnect comprises of IEEE 802.3 Ethernet links, it is possible
   to provide redundant interconnect by means of IEEE 802.3ad Link
   Aggregation Groups.

4.2.2. Co-located Shared Interconnect

   In this scenario, the PEs within an RG are co-located in the same
   physical location (POP, CO). However, unlike the previous scenario,
   there are no dedicated links between the PEs. The interconnect for
   ICCP is provided through the core network to which the PEs are
   connected. Figure 3 depicts this model.

Martini, et al.                                                 [Page 6]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

           +=================+     +-----------------+
           |CO               |     |                 |
           |  +-----+        |     |                 |
           |  | PE1 |________|_____|                 |
           |  |     |<=================+             |
           |  +-----+   ICCP |     |  ||             |
           |                 |     |  ||             |
           |                 |     |  ||   Core      |
           |                 |     |  ||  Network    |
           |  +-----+        |     |  ||             |
           |  | PE2 |________|_____|  ||             |
           |  |     |<=================+             |
           |  +-----+        |     |                 |
           |                 |     |                 |
           +=================+     +-----------------+

   Figure 3: ICCP Co-located PEs Shared Interconnect Scenario

   Given that the PEs in the RG are connected over the Packet Switched
   Network (PSN), then PSN Layer mechanisms can be leveraged to ensure
   the resiliency of the interconnect against connectivity failures. For
   example, it is possible to employ RSVP LSPs with FRR and/or end-to-
   end backup LSPs.

4.2.3. Geo-redundant Dedicated Interconnect

   In this variation, the PEs within a Redundancy Group are located in
   different physical locations to provide geographic redundancy. This
   may be desirable, for example, to protect against natural disasters
   or the like. A dedicated interconnect is provided to link the PEs,
   which is a costly option, especially when considering the possibility
   of providing multiple such links for interconnect robustness. Because
   of this particular reason, it is anticipated that this interconnect
   scenario will not be common for most commercial applications. The
   resiliency mechanisms for the interconnect are similar to those
   highlighted in the co-located interconnect counterpart.

Martini, et al.                                                 [Page 7]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

           +=================+     +-----------------+
           |CO 1             |     |                 |
           |  +-----+        |     |                 |
           |  | PE1 |________|_____|                 |
           |  |     |        |     |                 |
           |  +-----+        |     |                 |
           +=====||==========+     |                 |
                 || ICCP           |       Core      |
           +=====||==========+     |      Network    |
           |  +-----+        |     |                 |
           |  | PE2 |________|_____|                 |
           |  |     |        |     |                 |
           |  +-----+        |     |                 |
           |CO 2             |     |                 |
           +=================+     +-----------------+

   Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario

4.2.4. Geo-redundant Shared Interconnect

   In this scenario, the PEs of an RG are located in different physical
   locations and the interconnect for ICCP is provided over the PSN
   network to which the PEs are connected. This interconnect option is
   more likely to be the one used for geo-redundancy as it is more
   economically appealing compared to the geo-redundant dedicated
   interconnect. The resiliency mechanisms that can be employed to
   guarantee the robustness of the ICCP transport are PSN Layer
   mechanisms as has been described in a previous section.

           +=================+     +-----------------+
           |CO 1             |     |                 |
           |  +-----+        |     |                 |
           |  | PE1 |________|_____|                 |
           |  |     |<=================+             |
           |  +-----+   ICCP |     |  ||             |
           +=================+     |  ||             |
                                   |  ||   Core      |
           +=================+     |  ||  Network    |
           |  +-----+        |     |  ||             |
           |  | PE2 |________|_____|  ||             |
           |  |     |<=================+             |
           |  +-----+        |     |                 |
           |CO 2             |     |                 |
           +=================+     +-----------------+

   Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario

Martini, et al.                                                 [Page 8]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

4.3. ICCP Requirements

   The Inter-chassis Communication Protocol should satisfy the following
   requirements:

        -i. Provide control channel for communication between PEs in
            Redundancy Group (RG). Nodes maybe co-located or remote
            (refer to Interconnect Scenarios section above). It is
            expected that client applications which make use of ICCP
            services will only use this channel to communicate control
            information and not data-traffic. As such the protocol
            should cater for low-bandwidth, low-delay and highly
            reliable message transfer.

       -ii. Accommodate multiple client applications (e.g. multi-chassis
            LACP, PW redundancy, SONET APS, etc...). This implies that
            the messages should be extensible (e.g. TLV-based) and the
            protocol should provide a robust application registration
            and versioning scheme.

      -iii. Provide reliable message transport and in-order delivery
            between nodes in a RG with secure authentication mechanisms
            built into the protocol. The redundancy applications that
            are clients of ICCP expect reliable message transfer, and as
            such will assume that the protocol takes care of flow-
            control and retransmissions. Furthermore, given that the
            applications will rely on ICCP to communicate data used to
            synchronize state-machines on disparate nodes, it is
            critical that ICCP guarantees in-order message delivery.
            Loss of messages or out-of-sequence messages would have
            adverse side-effects to the operation of the client
            applications.

       -iv. Provide a common mechanism to actively monitor the health of
            PEs in an RG.  This mechanism will be used to detect PE node
            failure and inform the client applications. The applications
            require this to trigger failover according to the procedures
            of the employed redundancy protocol on the AC and PW. It is
            desired to achieve sub-second detection of loss of remote
            node (~ 50 - 150 msec) in order to give the client
            applications (redundancy mechanisms) enough reaction time to
            achieve sub-second service restoration time.

        -v. Provide asynchronous event-driven state update, independent
            of periodic messages, for immediate notification of client
            applications' state changes.  In other words, the
            transmission of messages carrying application data should be
            on-demand rather than timer-based to minimize inter-chassis

Martini, et al.                                                 [Page 9]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

            state synchronization delay.

       -vi. Accommodate multi-link and multi-hop interconnect between
            nodes. When the devices within an RG are located in
            different physical locations, the physical interconnect
            between them will comprise of a network rather than a link.
            As such, ICCP should accommodate the case where the
            interconnect involves multiple hops. Furthermore, it is
            possible to have multiple (redundant) paths or interconnects
            between a given pair of devices. This is true for both the
            co-located and geo-redundant scenarios. ICCP should handle
            this as well.

      -vii. Ensure transport security between devices in an RG. This is
            especially important in the scenario where the members of an
            RG are located in different physical locations and connected
            over a shared (e.g. PSN) network.

     -viii. Must allow operator to statically configure members of RG.
            Auto-discovery may be considered in the future.

       -ix. Allow for flexible RG membership. It is expected that only
            two nodes per an RG will cover most of the redundancy
            applications for common deployments.  However, ICCP should
            not preclude supporting more than two nodes in an RG by
            virtue of design.  Furthermore, it is required to allow a
            single node to be member of multiple RGs simultaneously.

5. ICC LDP Protocol extension Specification

   To address the requirements identified in the previous section, ICCP
   is modeled to comprise of three layers:

        -i. Application Layer: This provides the interface to the
            various redundancy applications that make use of the
            services of ICCP. ICCP is concerned with defining common
            connection management procedures and the formats of the
            messages exchanged at this layer; however, beyond that, it
            does not impose any restrictions on the procedures or
            state-machines of the clients, as these are deemed
            application-specific and lie outside the scope of ICCP.
            This guarantees implementation inter-operability without
            placing any unnecessary constraints on internal design
            specifics.

Martini, et al.                                                [Page 10]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

       -ii. Inter Chassis Communication (ICC) Layer: This layer
            implements the common set of services which ICCP offers to
            the client applications. It handles protocol versioning, RG
            membership, PE node identification and ICCP connection
            management.

      -iii. Transport Layer: This layer provides the actual ICCP message
            transport. It is responsible for addressing, route
            resolution, flow-control, reliable and in-order message
            delivery, connectivity resiliency/redundancy and finally PE
            node failure detection. The Transport layer may differ
            depending on the Physical Layer of the inter-connect.

5.1. LDP ICC capability advertisement

   When an RG is enabled on a particular PE, the capability of
   supporting ICCP must be advertised to all LDP peers. This is achieved
   by using the methods in [LDP-CAP] and advertising the ICCP LDP
   capability TLV. If an LDP peer supports the dynamic capability
   advertisement, this can be done by sending a new capability message
   with the S bit set for the ICCP capability TLV when the first RG is
   enabled on the PE. If the peer does not support dynamic capability
   advertisement, then the ICCP TLV MUST be included in the LDP
   initialization procedures in the capability parameter [LDP-CAP].

5.2. RG Membership Management

   ICCP defines a mechanism that enables PE nodes to manage their RG
   membership. When a PE is configured to be a member of an RG, it will
   first advertise the ICCP capability to its peers. Subsequently the PE
   sends an RG Connect message to the peers that have also advertised
   ICCP capability. The PE then waits for the peers to send their own RG
   Connect message, if they haven't already. For a given RG, the ICCP
   connection between two devices is considered to be operational only
   when both have sent and received ICCP RG Connect messages for that
   RG.

   If a PE that has sent an particular RG Connect message doesn't
   receive a corresponding RG Connect from a destination it will simply
   wait indefinitely for the corresponding RG Connect message. The RG
   will not become operational until the corresponding RG Connect
   Message has been received. If a PE that has sent an RG Connect
   message receives a Notification message with a NAK, it will stop
   attempting to bring up the ICCP connection immediately. A device MAY
   send a NAK for an RG Connect message if it is not a member of the RG,
   or if the maximum number of ICCP connections has been exceeded.

Martini, et al.                                                [Page 11]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   A PE sends an RG Disconnect message to tear down the ICCP connection
   for a given RG. This is a unilateral operation and doesn't require
   any acknowledgement from the other PEs. Note that the ICCP connection
   for an RG should be operational before any client application can
   make use of ICCP services in that RG.

5.3. Application Connection Management

   ICCP provides a common procedure by which applications on one PE can
   connect to their counterparts on another PE, for purpose of inter-
   chassis communication in the context of a given RG. The prerequisite
   for establishing an application connection is to have an operational
   ICCP RG connection between the two endpoints. It is assumed that the
   association of applications with RGs is known apriori, e.g. by means
   of device configuration. ICCP then sends Application Connect
   messages, on behalf of each client application, to each remote PE
   within the RG. The client may piggyback application-specific
   information in that Connect message, which for example can be used to
   negotiate parameters or attributes prior to bringing up the actual
   application connection. The procedures for bringing up the
   application connection are similar to those of the ICCP connection:
   An application connection between two nodes is up only when both
   nodes have sent and received Application Connect Messages. A PE can
   send a Notification Message to NAK the Application Connect message if
   the application doesn't exist or is not configured for that RG, or if
   the protocol version is not compatible. When a PE receives such a NAK
   notification, it should stop attempting to bring up the application
   connection.

   When an application is stopped on a device or it is no longer
   associated with an RG, it should signal ICCP to trigger sending an
   Application Disconnect message. This is a unilateral notification to
   the other PEs within an RG, and as such doesn't trigger any response.

5.4. Application Data Transfer

   When an application has information to transfer over ICCP it triggers
   the transmission of an Application Data message. ICCP guarantees in-
   order and loss-less delivery of data. An application may NAK a
   message or a set of one or more TLVs within a message by using the
   Notification Message with NAK TLV. Furthermore, an application may
   implement an ACK mechanism, if deemed required, by defining an
   application-specific TLV to be transported in an Application Data
   message.

Martini, et al.                                                [Page 12]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

6. ICCP PE Node Failure Detection Mechanism

   ICCP provides its client applications a notification when a remote PE
   that is member of the RG fails. This is used by the client
   applications to trigger failover according to the procedures of the
   employed redundancy protocol on the AC and PW. To that end, ICCP does
   not define its own KeepAlive mechanism for purpose of monitoring the
   health of remote PE nodes, but rather reuses existing fault detection
   mechanisms. The following mechanisms may be used by ICCP to detect PE
   node failure:

     + Loss of LDP Session

       Loss of the LDP session with a PE in an RG can be used to
       indicate to the local device that the remote PE is down. This can
       be, for example, due to the TCP connection being reset. This
       requires that the transport path for ICCP (and the underlying LDP
       session) is protected by some Layer 2 or Layer 3 resiliency
       mechanism.

     + BFD

       Run a BFD session [BFD] between the PEs that are members of a
       given RG, and use that to detect PE node failure. This assumes
       that resiliency mechanisms are in place to protect connectivity
       to the remote PE nodes, and hence loss of BFD periodic messages
       from a given PE node can only mean that the node itself has
       failed.

     + IP Reachability Monitoring

       It is possible for a PE to monitor IP layer connectivity to other
       members of an RG that are participating in IGP/BGP. When
       connectivity to a given PE is lost, the local PE interprets that
       to mean loss of the remote PE node.  This assumes that resiliency
       mechanisms are in place to protect the route to the remote PE
       nodes, and hence loss of IP reachability to a given node can only
       mean that the node itself has failed.

Martini, et al.                                                [Page 13]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

7. ICCP Message Formats

   This section defines the messages exchanged at the Application and
   ICC layers.

7.1. Encoding ICC into LDP messages

   ICCP requires reliable, in order, state-full message delivery, as
   well as capability negotiation between PEs. The LDP protocol offers
   all these features, and is already in wide use in the applications
   that would also require the ICCP protocol extensions. For these
   reasons, ICCP takes advantage of the already defined LDP protocol
   infrastructure.  [RFC5036] Section 3.5 defines a generic LDP message
   structure. A new set of LDP message types is defined to communicate
   the ICCP information. LDP message types in the range of 0x700 to
   0x7ff will be used for ICC.

   Message types are allocated by IANA, and requested in the IANA
   section below.

7.1.1. ICC Header

   Every ICCP message comprises of an ICC specific LDP Header followed
   by an ICCP message. The format of the ICC Header is as follows:

Martini, et al.                                                [Page 14]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|   Message Type              |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ICC RG ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Mandatory Parameters                      |
   ~                                                               ~
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Optional Parameters                       |
   ~                                                               ~
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U-bit

       Unknown message bit.  Upon receipt of an unknown message, if U is
       clear (=0), a notification is returned to the message originator;
       if U is set (=1), the unknown message is silently ignored.  The
       following sections which define messages specify a value for the
       U-bit.

     + Message Type

       Identifies the type of the ICCP message, must be in the range of
       0x0700 to 0x07ff.

     + Message Length

       Two octet integer specifying the total length of this message in
       octets, excluding the U-bit, Message Type and Length fields.

     + Message ID

       Four octet value used to identify this message.  Used by the
       sending PE to facilitate identifying RG Notification messages

Martini, et al.                                                [Page 15]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

       that may apply to this message.  A PE sending an RG Notification
       message in response to this message SHOULD include this Message
       ID in the "NAK TLV" of the RG Notification message; see Section
       "RG Notification Message".

     + ICC RG ID

       Four octects unsigned integer designating the Redundancy Group
       which the sending device is member of. RG ID value 0x00000000 is
       reserved by the protocol.

     + Mandatory Parameters

       Variable length set of required message parameters.  Some
       messages have no required parameters.

       For messages that have required parameters, the required
       parameters MUST appear in the order specified by the individual
       message specifications in the sections that follow.

     + Optional Parameters

       Variable length set of optional message parameters.  Many
       messages have no optional parameters.

       For messages that have optional parameters, the optional
       parameters may appear in any order.

7.1.2. Message Encoding

   The generic format of an ICC parameter is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|       Type                |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV(s)                                                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U-bit

       Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
       (=0), a notification MUST be returned to the message originator
       and the entire message MUST be ignored; if U is set (=1), the

Martini, et al.                                                [Page 16]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

       unknown TLV MUST be silently ignored and the rest of the message
       processed as if the unknown TLV did not exist. The sections
       following that define TLVs specify a value for the U-bit.

     + F-bit

       Forward unknown TLV bit. This bit applies only when the U-bit is
       set and the LDP message containing the unknown TLV is to be
       forwarded. If F is clear (=0), the unknown TLV is not forwarded
       with the containing message; if F is set (=1), the unknown TLV is
       forwarded with the containing message. The sections following
       that define TLVs specify a value for the F-bit. By setting both
       the U- and F-bits, a TLV can be propagated as opaque data through
       nodes that do not recognize the TLV.

     + Type

       Fourteen bits indicating the parameter type.

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + TLV(s):  A set of 0 or more TLVs, that vary according to the
       message type.

7.2. RG Connect Message

   The RG Connect Message is used to establish ICCP connection in
   addition to individual Application connections between PEs in an RG:
   an RG Connect message with no "Application-specific connect TLVs"
   signals establishment of the base ICCP connection. RG Connect
   messages with appropriate "Application-specific connect TLVs" signal
   the establishment of Application connections, in addition to the base
   ICCP connection (if not already established).  A PE sends an RG
   Connect Message to declare its membership in a Redundancy Group. One
   such message should be sent to each PE that is member of the same RG.
   The set of PEs to which RG Connect Messages should be transmitted is
   known via configuration or an auto-discovery mechanism that is
   outside the scope of this specification. If a device is member of
   multiple RGs, it must send separate RG Connect Messages for each RG
   even if the receiving device(s) happen to be the same.

   The format of the RG Connect Message is as follows:

Martini, et al.                                                [Page 17]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

        -i. ICC header with Message type = "RG Connect Message" (0x0700)
       -ii. "Sender Name TLV"
      -iii. "Application specific connect TLV"

   The currently defined Application-specific connect TLVs are:

     + PW Redundancy Connect TLV

   The details of these TLVs are discussed in the "Application TLVs"
   section.

   The RG Connect message can contain zero, one or more Application-
   specific connect TLVs. Multiple application connect TLVs can be sent
   in a single message, or multiple messages can be sent containing
   different application connect TLVs, but no application connect TLV
   can be sent more than once.

7.2.1. Sender Name TLV

   A TLV that carries the hostname of the sender encoded in UTF-8. This
   is used primarily for purpose of management of the RG and easing
   network operations.  The specific format is shown below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|           Type            |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sender Name                                                  |
   +                                             +-+-+-+-+-+-+-+-+-+
   ~                                             ~
   |      ...                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U=F=0

     + Type set to "ICC sender name"  Parameter type (from ICC parameter
       name space).

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

Martini, et al.                                                [Page 18]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

     + Sender Name

       Hostname of sending device encoded in UTF-8, and SHOULD not
       exceed 80 characters.

7.3. RG Disconnect Message

   The RG Disconnect Message serves dual-purpose: to signal that a
   particular Application connection is being closed within an RG, or
   that the ICCP connection itself is being disconnected because the PE
   wishes to leave the RG.  The format of this message is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|   Message Type=0x0701       |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ICC RG ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ICCP Status Code                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Optional Application-specific Disconnect TLVs       |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Optional Parameter TLVs                          |
   +                                                               +
   |                                                               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U-bit

       U=0

     + Message Type

       The message type for RG Disconnect Message is set to (0x0701)

     + Length

       Length of the TLV in octets excluding the U-bit, Message Type,
       and Message Length fields.

Martini, et al.                                                [Page 19]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

     + Message ID

       Defined in the "ICC Header" section above.

     + ICC RG ID

       Defined in the "ICC Header" section above.

     + ICCP Status Code

       A status code that reflects the reason for the disconnect
       message.  Allowed values are "RG Removed" and "Application
       Removed from RG".

     + Optional Application-specific Disconnect TLVs

       Zero, one or more Application-specific Disconnect TLVs which are
       defined later in the document. If the RG Disconnect message has a
       status code of "RG Removed", then it should not contain any
       Application-specific Disconnect TLVs, as the sending PE is
       signaling that it has left the RG and, thus, is disconnecting the
       entire ICCP connection, with all associated client application
       connections. If the message has a status code of "Application
       Removed from RG", then it should contain one or more
       Application-specific Disconnect TLVs, as the sending PE is only
       tearing down the connection for the specified applications. Other
       applications, and the base ICCP connection are not to be
       affected.

     + Optional Parameter TLVs

       None are defined for this message in this document.

7.4. RG Notification Message

   A PE sends an RG Notification Message to indicate one of the
   following:  to reject an ICCP connection, to reject an application
   connection, to NAK an entire message or to NAK one or more TLV(s)
   within a message. The Notification message can only be sent to a PE
   that is already part of an RG.

   The format of the Notification Message is:

        -i. ICC header with Message type = "RG Notification Message"
            (0x0702)

Martini, et al.                                                [Page 20]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

       -ii. Notification Message TLVs.

   The currently defined Notification message TLVs are:

        -i. Sender Name TLV
       -ii. NAK TLV.

7.4.1. Notification Message TLVs

   The Sender Name TLV uses the same format as in the RG Connect
   message, and was described above.

   The NAK TLV is defined 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|         Type=0x0002       |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ICCP Status Code                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Rejected Message ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Optional Rejected TLV(s)                     |
   +                                                               +
   |                                                               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U,F Bits

       both U and F are set to 0.

     + Type

       set to "NAK TLV" (0x0002)

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + ICCP Status Code

       A status code the reflects the reason for the NAK TLV. Allowed
       values are:

Martini, et al.                                                [Page 21]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

            -i. Unknown RG (0x00010001)

                This code is used to reject a new incoming ICCP
                connection for an RG that is not configured on the local
                PE. When this code is used, the Rejected Message ID
                field must contain the message ID of the rejected "RG
                Connect" message.

           -ii. ICCP Connection Count Exceeded (0x00010002)

                This is used to reject a new incoming ICCP connection
                that would cause the local PE's ICCP connection count to
                exceed its capabilities. When this code is used, the
                Rejected Message ID field must contain the message ID of
                the rejected "RG Connect" message.

          -iii. Application Connection Count Exceeded (0x00010003)

                This is used to reject a new incoming application
                connection that would cause the local PE's ICCP
                connection count to exceed its capabilities. When this
                code is used, the Rejected Message ID field must contain
                the message ID of the rejected "RG Connect" message and
                the corresponding Application Connect TLV must be
                included in the "Optional Rejected TLV".

           -iv. Application not in RG (0x00010004)

                This is used to reject a new incoming application
                connection when the local PE doesn't support the
                application, or the application is not configured in the
                RG. When this code is used, the Rejected Message ID
                field must contain the message ID of the rejected "RG
                Connect" message and the corresponding Application
                Connect TLV must be included in the "Optional Rejected
                TLV".

            -v. Incompatible Protocol Version (0x00010005)

                This is used to reject a new incoming application
                connection when the local PE has an incompatible version
                of the application. When this code is used, the Rejected
                Message ID field must contain the message ID of the
                rejected "RG Connect" message and the corresponding
                Application Connect TLV must be included in the
                "Optional Rejected TLV".

Martini, et al.                                                [Page 22]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

           -vi. Rejected Message (0x00010006)

                This is used to reject an RG Application Data message,
                or one or more TLV(s) within the message.  When this
                code is used, the Rejected Message ID field must contain
                the message ID of the rejected "RG Application Data"
                message.

          -vii. ICCP Administratively Disabled (0x00010007)

                This is used to reject any ICCP messages from a peer
                from which the PE is not allowed to exchenge ICCP
                messages due to local administrative policy.

         + Rejected Message ID If non-zero, 32-bit value that identifies
           the peer message to which the NAK TLV refers. If zero, no
           specific peer message is being identified.

         + Optional Rejected TLV(s)

           A set of one or more TLVs that were rejected. If the entire
           last message received is rejected, no TLVs will be present.
           However, if only specific TLVs were rejected then those TLVs
           MUST be echoed in this field.

7.5. RG Application Data Message

   The RG Application Data Message is used to transport application data
   between PEs within an RG. A single message can be used to carry data
   from multiple applications, as long as all these applications are
   part of the same RG. Such multiplexing is possible because the
   transported TLVs are application specific which allows for
   identifying the target application for each TLV at the receiving
   side. The format of the Application Data Message is:

        -i. ICC header with Message type = "RG Application Data Message"
            (0x703)
       -ii. "Application specific TLVs"

   The details of these TLVs are discussed in the "Application TLVs"
   section.

Martini, et al.                                                [Page 23]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

7.6. Application TLVs

7.6.1. Pseudowire Redundancy (PW-RED) Application TLVs

   This section discusses the ICCP TLVs for the Pseudowire Redundancy
   application.

7.6.1.1. PW-RED Connect TLV

   This TLV is included in the RG Connect message to signal the
   establishment of PW-RED application connection.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Type=0x0010             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Protocol Version         |   Optional Sub-TLVs           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                                               |
   +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U and F Bits

       Both are set to 0.

     + Type

       set to 0x0010 for "PW-RED Connect TLV"

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + Protocol Version

       The version of this particular protocol for the purposes of ICCP.
       This is set to 0x0001.

Martini, et al.                                                [Page 24]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

     + Optional Sub-TLVs

       There are no optional Sub-TLVs defined for this version of the
       protocol.

7.6.1.2. PW-RED Disconnect TLV

   This TLV is used in a RG Disconnect Message to indicate that the
   connection for the PW-RED application is to be terminated.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Type=0x0011             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Sub-TLVs                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U and F Bits

       Both are set to 0.

     + Type

       set to 0x0011 for "PW-RED Disconnect TLV"

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + Optional Sub-TLVs

       There are no optional Sub-TLVs defined for this version of the
       protocol.

7.6.1.3. PW-RED Config TLV

   The PW-RED Config TLV is used in RG Application Data message and is
   composed of the following TLVs in the following order:
        -i. Service Name TLV
       -ii. PW ID TLV or Generalized PW ID TLV

   In the PW-RED Config TLV the U and F Bits are both are set to 0, and
   the TLV type is set to 0x0012.

Martini, et al.                                                [Page 25]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

7.6.1.4. Service Name TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Type                    |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Service Name                           |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U and F Bits

       Both are set to 0.

     + Type

       set to 0x0013 for "Service Name TLV"

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + Service Name

       The name of the L2VPN service instance encoded in UTF-8 format
       and up to 80 character in length.

7.6.1.5. PW ID TLV

   This TLV is used to communicate the configuration of PWs for VPWS.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Type                    |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Peer ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PW ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Martini, et al.                                                [Page 26]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

     + U and F Bits

       Both are set to 0.

     + Type

       set to 0x0014 for "PW ID TLV"

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + Peer ID

       Four octet LDP Router ID of the peer at the far end of the PW.

     + Group ID

       Same as Group ID in [PWE3-LDP] section 5.2.

     + PW ID

       Same as PW ID in [PWE3-LDP] section 5.2.

7.6.1.6. Generalized PW ID TLV

   This TLV is used to communicate the configuration of PWs for VPLS.

Martini, et al.                                                [Page 27]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Type = 0x0015           |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AGI Type    |    Length     |      Value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    AGI  Value (contd.)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AII Type    |    Length     |      Value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   SAII  Value (contd.)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AII Type    |    Length     |      Value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   TAII Value (contd.)                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     + U and F bits

       both set to 0.

     + Type

       set to 0x0015

     + Length

       Length of the TLV in octets excluding the U-bit, F-bit, Type, and
       Length fields.

     + AGI, AII, SAII and TAII

       defined in [RFC4447] section 5.3.2.

Martini, et al.                                                [Page 28]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

8. LDP Capability Negotiation

   As requited in [LDP-CAP] the following TLV is defined to indicate the
   ICCP capability:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| TLV Code Point=0x405      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |    Reserved   |  VER/Maj      |  Ver/Min      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

     - U-bit

       SHOULD be 1 (ignore if not understood).

     + F-bit

       SHOULD be 0 (don't forward if not understood).

     + TLV Code Point

       The TLV type, which identifies a specific capability. For the
       ICCP code point is requested in the IANA allocation section
       below.

     + S-bit The State Bit indicates whether the sender is advertising
       or withdrawing the ICCP capability. The State bit is used as
       follows:
             1 - The TLV is advertising the capability specified by the
                 TLV Code Point.

             0 - The TLV is withdrawing the capability specified by the
                 TLV Code Point.

     + Ver/Maj

       The major version revision of the ICCP protocol, this document
       specifies 1.0. This field is then set to 1

     + Ver/Min

       The minor version revision of the ICCP protocol, this document
       specifies 1.0. This field is then set to 0

Martini, et al.                                                [Page 29]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   ICCP capability is advertised to a LDP peer if there is at least one
   RG enabled on the local PE.

9. Client Applications

9.1. Pseudowire Redundancy Application Procedures

   This section defines the procedures for the Pseudowire Redundancy
   (PW-RED) Application.

9.1.1. Initial Setup

   When an RG is configured on a system and multi-chassis pseudowire
   redundancy is enabled in that RG, the PW-RED application should send
   an "RG Connect" message with "PW-RED Connect TLV" to each PE that is
   member of the same RG. When the system receives similar "RG Connect"
   messages from a PE, the two devices can start exchanging "RG
   Application Data" messages for the PW-RED application.

   If a system receives an "RG Connect" message with "PW-RED Connect
   TLV" that has an incompatible Protocol Version, it should reply with
   "RG Notification" message with "Incompatible Protocol Version" status
   code and the rejected "PW-RED Connect TLV".

   When the PW-RED application is disabled on the device, or the RG is
   de-configured, the system should send an "RG Disconnect" message with
   "PW-RED Disconnect TLV".

9.1.2. Pseudowire Configuration

   A system should advertise its local PW configuration to other PEs
   that are members of the same RG. This allows the PEs to build a view
   of the redundant nodes and pseudowires that are protecting the same
   service instances.  The advertisement should be initiated when the
   PW-RED application connection first comes up, as well as upon any
   subsequent PW configuration change. To that end, the system should
   send "RG Application Data" messages with "PW-RED Config TLV". It is
   possible to send configuration information for multiple PWs in a
   single "RG Application Data" message.

   The "Service Name TLV" is used on the receiving system for the
   purpose of associating PW information advertised by some PE with the
   corresponding AC information received over ICCP from that PE's AC
   redundancy application. The Service Name has a global context in an
   RG, so redundant PWs for the same service on disparate member PEs

Martini, et al.                                                [Page 30]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   should share the same Service Name, in order to be correlated.

9.1.3. Pseudowire Status Synchronization

   On a given PE, the forwarding status of the PW (Active or Standby) is
   derived from the state of the associated AC(s). This simplifies the
   operation of the multi-chassis redundancy solution (Figure 1) and
   eliminates the possibility of deadlock conditions between the AC and
   PW redundancy mechanisms. The rules by which the PW state is derived
   from the AC state are as follows:

     + VPWS

       For VPWS, there's a single AC per service instance.  If the AC is
       Active, then the PW status should be Active.  If the AC is
       Standby, then the PW status should be Standby.

     + VPLS

       For VPLS, there could be multiple ACs per service instance (i.e.
       VFI).  If AT LEAST ONE AC is Active, then the PW status should be
       Active.  If ALL ACs are Standby, then the PW status should be
       Standby.

   The PW-RED application does not synchronize PW status across chassis,
   per se.  Rather, the AC Redundancy application should synchronize AC
   status between chassis, in order to determine which AC (and
   subsequently which PE) is Active or Standby for a given service. When
   that is determined, each PE will then adjust its local PWs state
   according to the rules described above.

9.1.4. PE Node Failure

   When a PE node detects that a remote PE, that is member of the same
   RG, has gone down, the local PE examines if it has redundant PWs for
   the affected services. If the local PE has the highest priority
   (after the failed PE) then it becomes the active node for the
   services in question, and subsequently activates its associated PWs.

Martini, et al.                                                [Page 31]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

9.2. Attachment Circuit Redundancy Application Procedures

9.2.1. Common AC Procedures

   This section describes generic procedures for AC Redundancy
   applications, independent of the type of the AC (ATM, FR or
   Ethernet).

9.2.1.1. AC Failure

   When the AC Redundancy mechanism on the Active PE detects a failure
   of the AC, it should send an ICCP Application Data message to inform
   the redundant PEs of the need to take over.  The AC failures can be
   categorized into the following scenarios:

     + Failure of CE interface connecting to PE

     + Failure of CE uplink to PE

     + Failure of PE interface connecting to CE

9.2.1.2. PE Node Failure

   When a PE node detects that a remote PE, that is member of the same
   RG, has gone down, the local PE examines if it has redundant ACs for
   the affected services. If the local PE has the highest priority
   (after the failed PE) then it becomes the active node for the
   services in question, and subsequently activates its associated ACs.

9.2.1.3. PE Isolation

   When a PE node detects that is has been isolated from the core
   network (i.e. all core facing interfaces/links are not operational),
   then it should instruct its AC Redundancy mechanism to change the
   status of any active ACs to Standby. The AC Redundancy application
   should then send ICCP Application Data messages in order to trigger
   failover to a standby PE.

9.2.2. ATM AC Procedures

Martini, et al.                                                [Page 32]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

9.2.3. Frame Relay AC Procedures

9.2.4. Ethernet AC Procedures

10. Security Considerations

   The security considerations described in [RFC5036] and [RFC4447] that
   apply to the base LDP specification, and to the PW LDP control
   protocol extensions apply to the capability mechanism described in
   this document.

   The ICCP protocol is not intended to be applicable when the
   redundancy group spans PE in different administrative domains.
   Furthermore, implementations MUST provide a mechanism to select to
   which LDP peers the ICCP capability will be advertised, and from wich
   LDP peers the ICCP messages will be accepted.

11. IANA Considerations

11.1. MESSAGE TYPE NAME SPACE

   This document uses several new LDP message types, IANA already
   maintains a registry of name "MESSAGE TYPE NAME SPACE" defined by
   [RFC5036]. The following values are suggested for assignment:

      Message type  Description
       0x0700       RG Connect Message
       0x0701       RG Disconnect Message
       0x0702       RG Notification Message
       0x0703       RG Application Data Message

11.2. TLV TYPE NAME SPACE

   This document use a new LDP TLV type, IANA already maintains a
   registry of name "TLV TYPE NAME SPACE" defined by [RFC5036]. The
   following value is suggested for assignment:
      TLV Type Description
      0x405ICCP capability TLV.

Martini, et al.                                                [Page 33]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

11.3. ICC RG Parameter Type Space

   IANA needs to set up a registry of "ICC RG parameter type". These are
   14-bit values. Parameter Type values 1 through 0x000F are specified
   in this document, Parameter Type values 0x0010 through 0x1FFF are to
   be assigned by IANA, using the "Expert Review" policy defined in
   [RFC2434]. Parameter Type values 0x2000 through 0x2FFF, 0x3FFF, and 0
   are to be allocated using the IETF consensus policy defined in
   [RFC2434]. Parameter Type values 0x3000 through 0x3FFE are reserved
   for vendor proprietary extensions and are to be assigned by IANA,
   using the "First Come First Served" policy defined in [RFC2434]. A
   Parameter Type description is required for any assignment from this
   registry. Additionally, for the vendor proprietary extensions range a
   citation of a person or company name is also required. A document
   reference should also be provided.

   Initial ICC RG parameter type space value allocations are specified
   below:

   Parameter Type Description                       Reference
   -------------- --------------------------------- ---------
   0x0001         ICC sender name                   [RFCxxxx]
   0x0002         NAK TLV                           [RFCxxxx]

   0x0010         PW-RED Connect TLV                [RFCxxxx]
   0x0011         PW-RED Disconnect TLV             [RFCxxxx]
   0x0012         PW-RED Config TLV                 [RFCxxxx]
   0x0013         Service Name TLV                  [RFCxxxx]
   0x0014         PW ID TLV                         [RFCxxxx]
   0x0015         Generalized PW ID TLV             [RFCxxxx]

11.4. STATUS CODE NAME SPACE

   This document use several new Status codes, IANA already maintains a
   registry of name "STATUS CODE NAME SPACE" defined by [RFC5036]. The
   following values is suggested for assignment:  The "E" column is the
   required setting of the Status Code E-bit.
   Range/Value     E     Description                       Reference
   ------------- -----   ----------------------            ---------
   0x00010001      0     Unknown ICCP RG
   0x00010002      0     ICCP Connection Count Exceeded
   0x00010003      0     ICCP Application Connection
                         Count Exceeded
   0x00010004      0     ICCP Application not in RG
   0x00010005      0     Incompatible ICCP  Protocol Version
   0x00010006      0     ICCP Rejected Message

Martini, et al.                                                [Page 34]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   0x00010007      0     ICCP Administratively Disabled
   0x00010010      0     ICCP RG Removed
   0x00010011      0     ICCP Application Removed from RG

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

13. Intellectual Property Statement

   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-
   [email-masked].

Martini, et al.                                                [Page 35]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

14. Normative References

   [RFC5036] L. Andersson et al, "LDP Specification", RFC 5036,
        October 2007.

   [LDP-CAP] "LDP Capabilities", draft-ietf-mpls-ldp-capabilities-02.txt
         April 2008, ( Work in Progress )

   [PWE3-LDP] L. Martini et al, "Pseudowire Setup and Maintenance
        Using the Label Distribution Protocol", RFC 4447, April 2006.

   [IEEE-802.3] IEEE Std. 802.3-2005, "Part 3: Carrier Sense Multiple
        Access with Collision Detection (CSMA/CD) Access Method and
        Physical Layer Specifications", IEEE Computer Society, December
        2005.

15. Informative References

   none

16. Author Information

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: [email-masked]

   Samer Salam
   Cisco Systems, Inc.
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1
   e-mail: [email-masked]

   Ali Sajassi
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

Martini, et al.                                                [Page 36]

Internet Draft       draft-martini-pwe3-iccp-00.txt            June 2008

   Satoru Matsushima
   Softbank Telecom
   1-9-1, Higashi-Shinbashi, Minato-ku
   Tokyo 105-7313, JAPAN
   E-mail: [email-masked]

   Thomas D. Nadeau
   BT
   BT Centre
   81 Newgate Street
   London,   EC1A 7AJ
   United Kingdom
   E-mail: [email-masked]

Martini, et al.                                                [Page 37]
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3