Internet DRAFT - draft-ietf-pwe3-iccp

draft-ietf-pwe3-iccp









Internet Engineering Task Force                             Luca Martini
Internet Draft                                               Samer Salam
Intended status: Standards Track                             Ali Sajassi
Expires: September 27, 2014                                        Cisco

Matthew Bocci                                          Satoru Matsushima
Alcatel-Lucent                                                  Softbank

Thomas Nadeau
Brocade
                                                          March 27, 2014


      Inter-Chassis Communication Protocol for L2VPN PE Redundancy


                      draft-ietf-pwe3-iccp-16.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 27, 2014

Abstract

   This document specifies an inter-chassis communication protocol
   (ICCP) that enables Provider Edge (PE) device 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



Martini, et al.                                                 [Page 1]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   amongst the systems. It accommodates multi-chassis attachment circuit
   as well as pseudowire redundancy mechanisms.

















































Martini, et al.                                                 [Page 2]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014




Table of Contents

    1        Specification of Requirements  ........................   5
    2        Introduction  .........................................   5
    3        ICCP Overview  ........................................   5
    3.1      Redundancy Model & Topology  ..........................   5
    3.2      ICCP Interconnect Scenarios  ..........................   7
    3.2.1    Co-located Dedicated Interconnect  ....................   7
    3.2.2    Co-located Shared Interconnect  .......................   8
    3.2.3    Geo-redundant Dedicated Interconnect  .................   8
    3.2.4    Geo-redundant Shared Interconnect  ....................   9
    3.3      ICCP Requirements  ....................................  10
    4        ICC LDP Protocol Extension Specification  .............  12
    4.1      LDP ICCP Capability Advertisement  ....................  13
    4.2      RG Membership Management  .............................  13
    4.2.1    ICCP Connection State Machine  ........................  14
    4.3      Redundant Object Identification  ......................  17
    4.4      Application Connection Management  ....................  17
    4.4.1    Application Versioning  ...............................  18
    4.4.2    Application Connection State Machine  .................  19
    4.5      Application Data Transfer  ............................  22
    4.6      Dedicated Redundancy Group LDP session  ...............  22
    5        ICCP PE Node Failure / Isolation Detection Mechanism  .  23
    6        ICCP Message Formats  .................................  24
    6.1      Encoding ICC into LDP Messages   ......................  24
    6.1.1    ICC Header  ...........................................  24
    6.1.2    ICC Parameter Encoding  ...............................  26
    6.1.3    Redundant Object Identifier Encoding  .................  27
    6.2      RG Connect Message  ...................................  28
    6.2.1    ICC Sender Name TLV  ..................................  29
    6.3      RG Disconnect Message  ................................  29
    6.4      RG Notification Message  ..............................  32
    6.4.1    Notification Message TLVs  ............................  32
    6.5      RG Application Data Message  ..........................  36
    7        Application TLVs  .....................................  36
    7.1      Pseudowire Redundancy (PW-RED) Application TLVs  ......  36
    7.1.1    PW-RED Connect TLV  ...................................  36
    7.1.2    PW-RED Disconnect TLV  ................................  37
    7.1.2.1  PW-RED Disconnect Cause TLV  ..........................  38
    7.1.3    PW-RED Config TLV  ....................................  39
    7.1.3.1  Service Name TLV  .....................................  41
    7.1.3.2  PW ID TLV  ............................................  42
    7.1.3.3  Generalized PW ID TLV  ................................  43
    7.1.4    PW-RED State TLV  .....................................  44
    7.1.5    PW-RED Synchronization Request TLV  ...................  45
    7.1.6    PW-RED Synchronization Data TLV  ......................  47



Martini, et al.                                                 [Page 3]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    7.2      Multi-chassis LACP (mLACP) Application TLVs  ..........  48
    7.2.1    mLACP Connect TLV  ....................................  48
    7.2.2    mLACP Disconnect TLV  .................................  49
    7.2.2.1  mLACP Disconnect Cause TLV  ...........................  50
    7.2.3    mLACP System Config TLV  ..............................  50
    7.2.4    mLACP Aggregator Config TLV  ..........................  51
    7.2.5    mLACP Port Config TLV  ................................  53
    7.2.6    mLACP Port Priority TLV  ..............................  55
    7.2.7    mLACP Port State TLV  .................................  57
    7.2.8    mLACP Aggregator State TLV  ...........................  59
    7.2.9    mLACP Synchronization Request TLV  ....................  61
    7.2.10   mLACP Synchronization Data TLV  .......................  63
    8        LDP Capability Negotiation  ...........................  64
    9        Client Applications  ..................................  65
    9.1      Pseudowire Redundancy Application Procedures  .........  65
    9.1.1    Initial Setup  ........................................  66
    9.1.2    Pseudowire Configuration Synchronization  .............  66
    9.1.3    Pseudowire Status Synchronization  ....................  67
    9.1.3.1  Independent Mode  .....................................  68
    9.1.3.2  Master/Slave Mode  ....................................  69
    9.1.4    PE Node Failure or Isolation  .........................  69
    9.2      Attachment Circuit Redundancy Application Procedures  .  70
    9.2.1    Common AC Procedures  .................................  70
    9.2.1.1  AC Failure  ...........................................  70
    9.2.1.2  Remote PE Node Failure or Isolation  ..................  70
    9.2.1.3  Local PE Isolation  ...................................  70
    9.2.1.4  Determining Pseudowire State  .........................  71
    9.2.2    Multi-chassis LACP (mLACP) Application Procedures  ....  71
    9.2.2.1  Initial Setup  ........................................  71
    9.2.2.2  mLACP Aggregator and Port Configuration  ..............  73
    9.2.2.3  mLACP Aggregator and Port Status Synchronization  .....  74
    9.2.2.4  Failure and Recovery  .................................  76
   10        Security Considerations  ..............................  77
   11        Manageability Considerations  .........................  78
   12        IANA Considerations  ..................................  78
   12.1      MESSAGE TYPE NAME SPACE  ..............................  78
   12.2      TLV TYPE NAME SPACE  ..................................  78
   12.3      ICC RG Parameter Type Space  ..........................  79
   12.4      STATUS CODE NAME SPACE  ...............................  80
   13        Acknowledgments  ......................................  80
   14        Normative References  .................................  80
   15        Informative References  ...............................  81
   16        Author's Addresses  ...................................  81








Martini, et al.                                                 [Page 4]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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. 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 Layer 2 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
   or more Provider Edge nodes (PEs) forming a Redundancy Group (RG).
   The protocol supports multi-chassis redundancy mechanisms that can be
   employed on either the attachment circuits or pseudowires. A formal
   definition of the term chassis can be found in [RFC2922]. For the
   purpose of this document, a chassis is an L2VPN PE node.

   This document assumes that it is normal to run the Label Distribution
   Protocol (LDP) between the PEs in the RG, and that LDP components
   will in any case be present on the PEs to establish and maintain
   pseudowires. Therefore, ICCP is built as a secondary protocol running
   within LDP and taking advantage of the LDP session mechanisms and the
   underlying TCP and TCP-based security mechanisms already necessary
   for LDP operation.


3. ICCP Overview

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



Martini, et al.                                                 [Page 5]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   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


   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.1AX 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



Martini, et al.                                                 [Page 6]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   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.


3.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 packet switched network (PSN); for e.g., MPLS core network. This
   gives rise to a matrix of four interconnect scenarios, described
   next.


3.2.1. Co-located Dedicated Interconnect

   In this scenario, the PEs within an RG are co-located in the same
   physical location, e.g. point of presence (POP) or central office
   (CO). Furthermore, dedicated links provide the interconnect for ICCP
   among the PEs.

           +=================+     +-----------------+
           |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



Martini, et al.                                                 [Page 7]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   robustness of the ICCP interconnect. For example, if the interconnect
   comprises of IEEE 802.3 Ethernet links, it is possible to provide
   link redundancy by means of IEEE 802.1AX Link Aggregation Groups.


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

           +=================+     +-----------------+
           |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 Fast Re-Route (FRR)
   and/or end-to-end backup LSPs.


3.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. The
   resiliency mechanisms for the interconnect are similar to those



Martini, et al.                                                 [Page 8]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   highlighted in the co-located interconnect counterpart.

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

   Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario



3.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 the "Co-located Shared
   Interconnect" section above.


















Martini, et al.                                                 [Page 9]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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

   Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario



3.3. ICCP Requirements

   The requirements for the Inter-chassis Communication Protocol are as
   follows:

        -i. ICCP MUST Provide a control channel for communication
            between PEs in a Redundancy Group (RG). PE nodes may be co-
            located or remote (refer to "Interconnect Scenarios" section
            above). Client applications which make use of ICCP services
            MUST only use this channel to communicate control
            information and not data-traffic. As such the protocol
            SHOULD cater for relatively low bandwidth, low-delay and
            highly reliable message transfer.

       -ii. ICCP MUST 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. ICCP MUST 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,



Martini, et al.                                                [Page 10]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


            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. ICCP MUST provide a common mechanism to actively monitor the
            health of PEs in an RG. This mechanism will be used to
            detect PE node failure (or isolation from the MPLS network
            in case of shared interconnect), 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. The solution SHOULD
            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.s

        -v. ICCP SHOULD 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
            state synchronization delay.

       -vi. ICCP MUST 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 MUST 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 MUST handle
            this as well.

      -vii. ICCP MUST 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 network (e.g. PSN).  In
            particular, ICCP MUST NOT accept connections arbitrarily
            from any device; otherwise, the state of client applications
            might be compromised. Furthermore, even if an ICCP
            connection request appears to come from an eligible device,
            its source address may have been spoofed. Therefore, some
            means of preventing source address spoofing MUST be in
            place.





Martini, et al.                                                [Page 11]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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

       -ix. ICCP SHOULD 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.  ICCP SHOULD
            NOT preclude supporting more than two nodes in an RG by
            virtue of design. Furthermore, ICCP MUST allow a single node
            to be member of multiple RGs simultaneously.


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

       -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, Redundant Object identification, 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.











Martini, et al.                                                [Page 12]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


4.1. LDP ICCP Capability Advertisement

   When an RG is enabled on a particular PE, an LDP session MUST be
   created to every remote PE in that RG, if one does not already exist.
   Then, the capability of supporting ICCP MUST be advertised to all
   those LDP peers in that RG. This is achieved by using the methods in
   [RFC5561] 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 [RFC5561].


4.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 messages, if they haven't done so 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 a particular RG Connect message doesn't receive
   a corresponding RG Connect (or a Notification message rejecting the
   connection) from a destination, it will remain in a state expecting
   the corresponding RG Connect message (or Notification 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 rejecting the connection,
   with a NAK TLV (section 6.4.1), it will stop attempting to bring up
   the ICCP connection immediately.

   A device MUST reject an incoming RG Connect message if at least one
   of the following conditions is satisfied:

        -i. the PE is not a member of the RG;

       -ii. the maximum number of simultaneous ICCP connections that the
            PE can handle is exceeded.

   Otherwise, the PE MUST bring up the connection by responding to the
   incoming RG Connect message with an appropriate RG Connect.




Martini, et al.                                                [Page 13]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   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 MUST be operational before any client application can make
   use of ICCP services in that RG.


4.2.1. ICCP Connection State Machine

   A PE maintains an ICCP Connection State Machine instance for every
   ICCP connection with a remote peer in the RG. This state machine is
   separate from any Application Connection State Machine (section
   4.4.2). The ICCP Connection State Machine reacts only to RG Connect,
   RG Disconnect and RG Notification messages that do not contain any
   Application TLVs. Actions and state transitions in the Application
   Connection state machines have no effect on the ICCP Connection State
   Machine.

   The ICCP Connection state machine is defined to have six states as
   follows:

   -NON EXISTENT: This state is the starting point for the state
   machine.It indicates that no ICCP connection exists and that
   there's no LDP session established between the PEs.

   -INITIALIZED: This state indicates that an LDP session exists between
   the PEs but LDP ICCP Capabilitiy have not yet been exchanged between
   them.

   -CAPSENT: This state indicates that an LDP session exists between the
   PEs and that the local PE has avertized LDP ICCP Capability to its
   peer.

   -CAPREC: This state indicates that an LDP session exists between the
   PEs and that the local PE has both received and avertized LDP ICCP
   Capability from/to its peer.

   -CONNECTING: This state indicates that the local PE has initiated
   an ICCP connection to its peer, and is awaiting its response.

   -OPERATIONAL: This state indicates that the ICCP connection is
   operational.


   The state transition table and state transition diagram follow.

   ICCP Connection State Transition Table




Martini, et al.                                                [Page 14]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   STATE         EVENT                                    NEW STATE

   NON EXISTENT  LDP session established                  INITIALIZED

   INITIALIZED   Transmit LDP ICCP Capability             CAPSENT

                 Receive LDP ICCP Capability              CAPREC
                    Action: Transmit LDP ICCP Capability

                 LDP session torn down                    NON EXISTENT

   CAPSENT       Receive LDP ICCP Capability              CAPREC

                 LDP session torn down                    NON EXISTENT

   CAPREC        Transmit RG Connect Message              CONNECTING

                 Receive acceptable RG Connect Message    OPERATIONAL
                    Action: Transmit RG Connect Message

                 Receive any other ICCP Message           CAPREC
                    Action: Transmit NAK TLV in RG
                            Notification Message

                 LDP session torn down                    NON EXISTENT

   CONNECTING    Receive acceptable RG Connect Message    OPERATIONAL

                 Receive any other ICCP Message           CAPREC
                    Action: Transmit NAK TLV in RG
                            Notification Message

                 LDP session torn down                    NON EXISTENT

   OPERATIONAL   Receive acceptable RG Disconnect Message CAPREC

                 Transmit RG Disconnect Message           CAPREC

                 LDP session torn down                    NON EXISTENT


   ICCP Connection State Transition Diagram









Martini, et al.                                                [Page 15]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


                              +------------+
                              |            |
          +------------------>|NON EXISTENT|    LDP session torn down
          |                   |            |<--------------------------+
          |                   +------------+                           |
          |         LDP session  |    ^ LDP session                    |
          |         established  |    | torn down                      |
          |                      V    |                                |
          |                  +-----------+                             |
   LDP    |                  |           |  Tx LDP ICCP                |
   session|                  |INITIALIZED|    capability               |
   torn   |              +---|           |---------------+             |
   down   |  Rx other    |   +-----------+               |             |
          |  ICCP msg/   |Rx LDP ICCP                    |             |
          |   Tx NAK TLV |  capability/                  |             |
          |      +---+   |Tx LDP ICCP capability         |             |
          |      |   |   |                               |             |
          |      V   |   V                               V             |
          |   +-----------+   Rx LDP ICCP         +--------+           |
          +---|           |     capability        |        |           |
              |CAPREC     |<----------------------|CAPSENT |---------->+
          +---|           |-------------------+   |        |           |
          |   +-----------+                   |   +--------+           |
          |       ^    ^                      |                        |
   Tx     |       |    |                      |                        |
   RG     |       |    |Rx RG Disconnect msg  |                        |
   Connect|       |    | or                   |Rx RG Connect msg /     |
   Msg    |       |    |Tx RG Disconnect msg  | Tx RG Connect msg      |
          |       |    |                      V                        |
          |       |    |                    +------------+             |
          |       |    +--------------------|            |             |
          |       |                         |OPERATIONAL |------------>+
          |       |                         |            |             |
          |       |Rx other ICCP msg/       +------------+             |
          |       | Tx NAK TLV                    ^                    |
          |       |                               |                    |
          |      +----------+  Rx RG Connect msg  |                    |
          |      |          |---------------------+                    |
          +----->|CONNECTING|                                          |
                 |          |----------------------------------------->+
                 +----------+










Martini, et al.                                                [Page 16]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


4.3. Redundant Object Identification

   ICCP offers its client applications a uniform mechanism for
   identifying links, ports, forwarding constructs and more generally
   objects (e.g.  interfaces, pseudowires, VLANs, etc...) that are being
   protected in a redundant setup. These are referred to as Redundant
   Objects (RO). An example of an RO is a multi-chassis link-aggregation
   group that spans two PEs. ICCP introduces a 64-bit opaque identifier
   to uniquely identify ROs in an RG.  This identifier, referred to as
   Redundant Object ID (ROID), MUST match between RG members for the
   protected object in question. That allows separate systems in an RG
   to use a common handle to reference the protected entity irrespective
   of its nature (e.g. physical or virtual) and in a manner that is
   agnostic to implementation specifics. Client applications that need
   to synchronize state pertaining to a particular RO SHOULD embed the
   corresponding ROID in their TLVs.



4.4. Application Connection Management

   ICCP provides a common set of procedures 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 a
   priori, e.g. by means of device configuration. ICCP then sends an
   Application-specific Connect TLV (carried in RG Connect message), on
   behalf of each client application, to each remote PE within the RG.
   The client may piggyback application-specific information in that
   Connect TLV, 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 RG
   Connect Messages with the proper Application-specific Connect TLVs. A
   PE MUST send a Notification Message to reject an application
   connection request if one of the following conditions is encountered:

        -i. the application doesn't exist or is not configured for that
            RG;

       -ii. the application connection count exceeds the PE's
            capabilities.

   When a PE receives such a rejection notification, it MUST stop
   attempting to bring up the application connection until it receives a



Martini, et al.                                                [Page 17]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   new application connection request from the remote PE. This is done
   by responding to the incoming RG Connect message (carrying an
   Application-specific Connect TLV) with an appropriate RG Connect
   message (carrying a corresponding Application-specific Connect TLV).

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


4.4.1. Application Versioning

   During application connection setup time, a given application on one
   PE can negotiate with its counterpart on a peer PE the proper
   application version to use for communication. If no common version is
   agreed upon, then the application connection is not brought up. This
   is achieved through the following set of rules:

     - If an application receives an Application-specific Connect TLV
       with a version number that is higher than its own, it MUST send a
       Notification message with a NAK TLV indicating status code
       "Incompatible Protocol Version" and supplying the version that is
       locally supported by the PE.

     - If an application receives an Application-specific Connect TLV
       with a version number that is lower than its own, it MAY respond
       with an RG Connect that has an Application-specific Connect TLV
       using the same version that was received. Alternatively, the
       application MAY respond with a Notification message to reject the
       request using the "Incompatible Protocol Version" code, and
       supplying the version that is supported. The above allows an
       application to operate in either backwards compatible or
       incompatible mode.

     - If an application receives an Application-specific Connect TLV
       with a version that is equal to its own, then the application
       MUST honor or reject the request based on whether the application
       is configured for the RG in question, and whether or not the
       application connection count has been exceeded.










Martini, et al.                                                [Page 18]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


4.4.2. Application Connection State Machine

   A PE maintains an Application Connection State Machine instance per
   ICCP application for every ICCP connection with a remote PE in the
   RG. Each application's state machine reacts only to the RG Connect,
   RG Disconnect and RG Notification messages that contain an
   Application TLV specifying that particular application.

   The Application Connection state machine has six states as follows:

   -NON EXISTENT: This state indicates that the Application Connection
   does not exist since there is no ICCP connection between the PEs.

   -RESET: This state indicates that an ICCP connection is operational
   between the PEs, but that the Application Connection has not been
   initialized yet or has been resent.

   -CONNSENT: This state indicates that the local PE has requested
   initiation of an Application Connection with its peer, but has not
   received a response yet.

   -CONNREC: This state indicates that the local PE has received a
   request to initiate an Application Connection from its peer but has
   not responded yet.

   -CONNECTING: This state indicates that the local PE has transmitted
   to its peer an Application Connection message with the A-bit set
   to 1, and is awaiting the peer's response

   -OPERATIONAL: This state indicates that the Application Connection is
   operational.


   The state transition table and diagram follow.

   ICCP Application Connection State Transition Table















Martini, et al.                                                [Page 19]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   STATE          EVENT                                  NEW STATE

   NON EXISTENT   ICCP connection established            RESET

   RESET          ICCP connection torn down              NON EXISTENT

                  Transmit Application Connect TLV       CONNSENT

                  Receive Application Connect TLV        CONNREC

                  Receive any other Application TLV      RESET
                    Action: Transmit NAK TLV

   CONNSENT       Receive NAK TLV                        RESET

                  Receive Application Connect TLV        OPERATIONAL
                  with A-bit=1
                    Action: Transmit Application Connect
                    TLV with A-bit=1

                  Receive any other Application TLV      RESET
                    Action: Transmit NAK TLV

                  ICCP connection torn down              NON EXISTENT

   CONNREC        Transmit NAK TLV                       RESET

                  Transmit Application Connect TLV       CONNECTING
                  with A-bit=1

                  Receive Application Connect TLV        CONNREC

                  Receive any Application TLV except     RESET
                  Connect
                    Action: Transmit NAK TLV

                  ICCP connection torn down              NON EXISTENT

   CONNECTING     Receive Application Connect TLV        OPERATIONAL
                  with A-bit=1

                  Receive any other Application TLV      RESET
                    Action: Transmit NAK TLV

                  ICCP connection torn down              NON EXISTENT

   OPERATIONAL    Receive Application Disconnect TLV     RESET




Martini, et al.                                                [Page 20]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


                  Transmit Applicaton Disconnect TLV     RESET

                  ICCP connection torn down              NON EXISTENT


   ICCP Application Connection State Transition Diagram
                            +------------+
                            |            |
          +---------------->|NON EXISTENT|  ICCP connection torn down
          |                 |            |<--------------------------+
          |                 +------------+                           |
          |     ICCP connection|    ^ ICCP connection                |
          |       established  |    | torn down                      |
          |                    |    |                                |
          |                    V    |          Rx other App TLV/     |
          |                +-----------+<-----+  Tx NAK TLV          |
   ICCP   |    Rx App      |           |      |                      |
   connect|    Connect TLV |   RESET   |------+                      |
   torn   |  +-------------|           |---------------+             |
   down   |  |             +-----------+    Tx App     |             |
          |  |              ^  ^   ^  ^     Connect TLV|             |
          |  |      Tx NAK  |  |   |  |                |             |
          |  |      or      |  |   |  |                |             |
          |  |      Rx non  |  |   |  |                |             |
          |  |      Connect |  |   |  |                |             |
          |  V      TLV/Tx NAK |   |  |Rx NAK TLV      V             |
          | +-----------+   |  |   |  |or       +--------+           |
          +-|           |---+  |   |  +---------|        |           |
            |CONNREC    |      |   |   Rx other |CONNSENT|---------->+
          +-|           |-+    |   |   App TLV/ |        |           |
          | +-----------+ |    |   |     Tx NAK +--------+           |
          |           ^---+    |   |                 |Rx App Connect |
          |        Rx App      |   |                 |TLV (A=1) /    |
          |    Connect TLV     |   |Rx App Disconn   | Tx App        |
          |                    |   |or               | Connect TLV   |
          | Tx App Connect     |   |Tx App Disconn   V (A=1)         |
          | TLV (A=1)          |   |      +------------+             |
          |                    |   +------|            |             |
          |       Rx other App |          |OPERATIONAL |------------>+
          |       TLV / Tx NAK |          |            |             |
          |             +------+          +------------+             |
          |             |                       ^ Rx App Connect     |
          |    +----------+                     | TLV (A=1)          |
          |    |          |---------------------+                    |
          +--->|CONNECTING|                                          |
               |          |----------------------------------------->+
               +----------+




Martini, et al.                                                [Page 21]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


4.5. 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 reject 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 its own ACK mechanism, if deemed required, by defining an
   application-specific TLV to be transported in an Application Data
   message. Note that this document does not define a common ACK
   mechanism for applications.

   It is left up to the application to define the procedures to handle
   the situation where a PE receives a NAK TLV in response to a
   transmitted Application Data message. Depending on the specifics of
   the application, it may be favorable to have the PE, which sent the
   NAK, explicitly request retransmission of data. On the other hand,
   for certain applications it may be more suitable to have the original
   sender of the Application Data message handle retransmissions in
   response to a NAK. ICCP supports both models.


4.6. Dedicated Redundancy Group LDP session

   For certain ICCP applications, it is required to exchange a fairly
   large amount of RG information in a very short period of time. In
   order to better distribute the load in a multiple processor system,
   and to avoid head of line blocking to other LDP applications, it may
   be required to initiate a separate TCP/IP session between the two LDP
   speakers.

   This procedure is OPTIONAL, and does not change the operation of LDP
   or ICCP.

   A PE that requires a separate LDP session will advertise a separate
   LDP adjacency with a non-zero label space identifier. This will cause
   the remote peer to open a separate LDP session for this label space.
   No labels need to be advertised in this label space, as it is only
   used for one or a set of ICCP RGs. All relevant LDP and ICCP
   procedures still apply as described in the relevant documents.











Martini, et al.                                                [Page 22]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


5. ICCP PE Node Failure / Isolation Detection Mechanism

   ICCP provides its client applications a notification when a remote PE
   that is member of the RG is no longer reachable. In the case of
   dedicated interconnect, this indicates that the remote PE node has
   failed. Whereas, in the case of shared interconnect, this indicates
   that either the remote PE node has failed or that it has become
   isolated from the MPLS network.  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 Keep-Alive 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:

     - BFD

       Run a BFD session [RFC5880] 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.

   It is worth noting here that loss of the LDP session with a PE in an
   RG is not a reliable indicator that the remote PE itself is down. It
   is possible, for e.g. that the remote PE encounters a local event
   that leads to resetting the LDP session, while the PE node remains
   operational for purpose of traffic forwarding.












Martini, et al.                                                [Page 23]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


6. ICCP Message Formats

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


6.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 0x700 to 0x70F will be
   used for ICCP.

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


6.1.1. ICC Header

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























Martini, et al.                                                [Page 24]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=0x0005 (ICC RG ID)     |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ICC RG ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                   Mandatory ICC Parameters                    |
   ~                                                               ~
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                   Optional ICC 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 0x070F.

     - Message Length

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






Martini, et al.                                                [Page 25]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Message ID

       Four octet value used to identify this message.  Used by the
       sending PE to facilitate identifying RG Notification messages
       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
       6.4 "RG Notification Message".

     - ICC RG ID TLV

       A TLV of type 0x0005, length 4, containing 4 octets unsigned
       integer designating the Redundancy Group which the sending device
       is member of. RG ID value 0x00000000 is reserved by the protocol.

     - Mandatory ICC 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 ICC 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.


6.1.2. ICC Parameter 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)                                                      |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Martini, et al.                                                [Page 26]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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


6.1.3. Redundant Object Identifier Encoding

   The Redundant Object Identifier (ROID) is a generic opaque handle
   that uniquely identifies a Redundant Object (e.g. link, bundle, VLAN,
   etc...)  which is being protected in an RG. It is encoded 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ROID                             |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Martini, et al.                                                [Page 27]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   where: ROID is an 8 octets field encoded as an unsigned integer. The
   ROID value of 0 is reserved.

   The ROID is carried within application specific TLVs.


6.2. RG Connect Message

   The RG Connect Message is used to establish the ICCP RG connection in
   addition to individual Application connections between PEs in an RG.
   An RG Connect message with no "Application-specific connect TLV"
   signals establishment of the ICCP RG connection. Whereas, an RG
   Connect message with a valid "Application-specific connect TLV"
   signals the establishment of an Application connection, in addition
   to the ICCP RG connection if the latter is not already established.

   An implementation MAY send a dedicated RG Connect message to set up
   the ICCP RG connection and a separate RG Connect message per client
   application. However, all implementations MUST support the receipt of
   an RG Connect message that triggers the setup of the ICCP RG
   connection as well as a single Application connection simultaneously.

   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:

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

   The currently defined Application-specific connect TLVs are:

     - PW-RED Connect TLV (section 7.1.1)

     - mLACP Connect TLV (section 7.2.1)

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

   The RG Connect message can contain zero or one Application-specific
   connect TLV.



Martini, et al.                                                [Page 28]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


6.2.1. ICC Sender Name TLV

   A TLV that carries the hostname of the sender encoded in UTF-8
   [RFC3629]. 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 = 0x0001       |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sender Name                                                  |
   +                                             +-+-+-+-+-+-+-+-+-+
   ~                                             ~
   |      ...                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U=F=0

     - Type set to 0x0001 (from ICC parameter name space).

     - Length

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

     - Sender Name

       An administratively-assigned name of the sending device encoded
       in UTF-8 and limited to a maximum of 80 octets. This field does
       not include a terminating null character.


6.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 RG connection itself is being disconnected because the
   PE wishes to leave the RG. The format of this message is:











Martini, et al.                                                [Page 29]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type=0x0005 (ICC RG ID)     |           Length=4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ICC RG ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Disconnect Code TLV                          |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Optional Application-specific Disconnect TLV        |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              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.

     - Message ID

       Defined in the "ICC Header" section above.

     - ICC RG ID

       Defined in the "ICC Header" section above.






Martini, et al.                                                [Page 30]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Disconnect Code TLV

       The format of this TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|F|         Type=0x0004       |    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      ICCP Status Code                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U,F Bits

       both U and F are set to 0.

     - Type

       set to "Disconnect Code TLV" (0x0004)

     - Length

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

     - ICCP Status Code

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


     - Optional Application-specific Disconnect TLV

       Zero or one 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 MUST NOT contain any
       Application-specific Disconnect TLVs, as the sending PE is
       signaling that it has left the RG and, thus, is disconnecting the
       ICCP RG connection, with all associated client application
       connections. If the message has a status code of "Application
       Removed from RG", then it MUST contain exactly one Application-
       specific Disconnect TLV, as the sending PE is only tearing down
       the connection for the specified application. Other applications,
       and the ICCP RG connection are not to be affected.





Martini, et al.                                                [Page 31]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Optional Parameter TLVs

       None are defined for this message in this document. This is
       specified to allow for future extensions.


6.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 reject an entire message or to reject one or more
   TLV(s) within a message. The Notification message MUST only be sent
   to a PE that is already part of an RG.

   The RG Notification Message MUST only be used to reject messages or
   TLVs corresponding to a single ICCP application. In other words,
   there is a limit of at most a single ICCP application per RG
   Notification Message.

   The format of the RG Notification Message is:

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

   The currently defined Notification message TLVs are:

        -i. ICC Sender Name TLV
       -ii. Negative-Acknowledgement (NAK) TLV


6.4.1. Notification Message TLVs

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

   The NAK TLV is defined as follows:














Martini, et al.                                                [Page 32]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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 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 that reflects the reason for the NAK TLV. Allowed
       values are:
            -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.



Martini, et al.                                                [Page 33]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


          -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 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 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 TLV".

           -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 exchange ICCP
                messages due to local administrative policy.

     - Rejected Message ID

       If non-zero, four octets value that identifies the peer message
       to which the NAK TLV refers. If zero, no specific peer message is



Martini, et al.                                                [Page 34]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


       being identified.

     - Optional TLV(s)

       A set of one or more optional TLVs. If the status code is
       "Rejected Message" then this field contains the TLV(s) that were
       rejected. If the entire message is rejected, all its TLVs MUST be
       present in this field; otherwise, the subset of TLVs that were
       rejected MUST be echoed in this field.

       If the status code is "Incompatible Protocol Version" then this
       field contains the original "Application Connect TLV" sent by the
       peer, in addition to the "Requested Protocol Version TLV" defined
       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=0x0003             |    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Connection Reference        |   Requested Version           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0003 for "Requested Protocol Version TLV"

     - Length

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

     - Connection Reference

       This field is set to the Type field of the Application specific
       Connect TLV that was rejected because of incompatible version.

     - Requested Version

       The version of the application supported by the transmitting
       device. For this version of the protocol it is set to 0x0001.





Martini, et al.                                                [Page 35]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


6.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 only one application. Multiple application TLVs are allowed in a
   single message, as long as all of these TLVs belong to the same
   application. 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.  All application specific TLVs in one RG Application Data
   Message MUST belong to a single application but MAY reference
   different ROs.


7. Application TLVs

7.1. Pseudowire Redundancy (PW-RED) Application TLVs

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


7.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         |A|         Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Optional Sub-TLVs                        |
   ~                                                               ~
   |                                                               |
   +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Martini, et al.                                                [Page 36]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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

     - A bit

       Acknowledgement Bit. Set to 1 if the sender has received a PW-RED
       Connect TLV from the recipient. Otherwise, set to 0.

     - Reserved

       Reserved for future use.

     - Optional Sub-TLVs

       There are no optional Sub-TLVs defined for this version of the
       protocol.  This document does not impose any resrictions on the
       length of the sub-TLVs.


7.1.2. PW-RED Disconnect TLV

   This TLV is used in an 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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Martini, et al.                                                [Page 37]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - 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

       The only optional Sub-TLV defined for this version of the
       protocol is the "PW-RED Disconnect Cause" TLV defined in Section
       7.1.2.1.


7.1.2.1. PW-RED Disconnect Cause 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=0x0019             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Disconnect Cause String                  |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0019 for "PW-RED Disconnect Cause TLV"

     - Length

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







Martini, et al.                                                [Page 38]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Disconnect Cause String

       Variable length string specifying the reason for the disconnect,
       encoded in UTF-8. The string does not include a terminating null
       character. Used for network management.


7.1.3. PW-RED Config TLV

   The PW-RED Config TLV is used in the RG Application Data message and
   has the following format:

    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 = 0x0012           |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ROID                             |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PW Priority              |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Service Name TLV                             |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            PW ID TLV or Generalized PW ID TLV                 |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0012 for "PW-RED Config TLV"

     - Length

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






Martini, et al.                                                [Page 39]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - ROID

       As defined in Section 6.1.3.

     - PW Priority

       Two octets Pseudowire Priority. Used to indicate which PW has
       better priority to go into Active state. Numerically lower
       numbers are better priority. In case of a tie, the PE with the
       numerically lower identifier (i.e. IP Address) has better
       priority.

     - Flags

       Valid values are:


            -i. Synchronized (0x01)

                Indicates that the sender has concluded transmitting all
                pseudowire configuration for a given service.

           -ii. Purge Configuration (0x02)

                Indicates that the pseudowire is no longer configured
                for PW-RED operation.

          -iii. Independent Mode (0x04)

                Indicates that the pseudowire is configured for
                redundancy using the Independent Mode of operation, per
                section 5.1 of [RFC6870].

           -iv. Independent Mode with Request Switchover (0x08)

                Indicates that the pseudowire is configured for
                redundancy using the Independent Mode of operation with
                the use of the "Request Switchover" bit, per section 6.3
                of [RFC6870].

            -v. Master Mode (0x10)

                Indicates that the pseudowire is configured for
                redundancy using the Master/Slave Mode of operation,
                with the advertising PE acting as Master, per section
                5.2 of [RFC6870].





Martini, et al.                                                [Page 40]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


           -vi. Slave Mode (0x20)

                Indicates that the pseudowire is configured for
                redundancy using the Master/Slave Mode of operation,
                with the advertising PE acting as Slave, per section 5.2
                of [RFC6870].

     - Sub-TLVs

       The "PW-RED Config TLV" includes the following two sub-TLVs:


            -i. Service Name TLV

           -ii.  One of PW ID TLV or Generalized PW ID TLV


       The format of the sub-TLVs is defined in Sections 7.1.3.1 through
       7.1.3.3.


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






Martini, et al.                                                [Page 41]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Service Name

       The name of the L2VPN service instance encoded in UTF-8 format
       and up to 80 octets in length. The string does not include a
       terminating null character.


7.1.3.2. 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                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - 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 [RFC4447] section 5.2.







Martini, et al.                                                [Page 42]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - PW ID

       Same as PW ID in [RFC4447] section 5.2.


7.1.3.3. Generalized PW ID TLV

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

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





Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


7.1.4. PW-RED State TLV

   The PW-RED State TLV is used in the RG Application Data Message. This
   TLV is used by a device to report its PW status to other members in
   the RG.

   The format of this TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|   Type=0x0016             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ROID                             |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local PW State                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Remote PW State                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0016 for PW-RED State TLV.

     - Length

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

     - ROID

       As defined in Section 6.1.3.

     - Local PW State

       The status of the PW as determined by the sending PE, encoded in
       the same format as the "Status Code" field of the "PW Status TLV"
       defined in [RFC4447] and extended in [RFC6870].






Martini, et al.                                                [Page 44]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Remote PW State

       The status of the PW as determined by the remote peer of the
       sending PE. Encoded in the same format as the "Status Code" field
       of the "PW Status TLV" defined in [RFC4447] and extended in
       [RFC6870].


7.1.5. PW-RED Synchronization Request TLV

   The PW-RED Synchronization Request TLV is used in the RG Application
   Data message. This TLV is used by a device to request from its peer
   to retransmit configuration or operational state. The following
   information can be requested:

     - configuration and/or state for one or more pseudowires

     - configuration and/or state for all pseudowires

     - configuration and/or state for all pseudowires in a given service

       The format of the TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|F|   Type=0x0017             |    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Request Number           |C|S|    Request Type           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Optional Sub-TLVs                          |
       ~                                                               ~
       |                                                               |
       +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             ...                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0017 for "PW-RED Synchronization Request TLV"






Martini, et al.                                                [Page 45]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Length

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

     - Request Number

       2 octets. Unsigned integer uniquely identifying the request. Used
       to match the request with a response. The value of 0 is reserved
       for unsolicited synchronization, and MUST NOT be used in the PW-
       RED Synchronization Request TLV. Given the use of TCP, there are
       no issues associated with the wrap-around of the Request Number.

     - C Bit

       Set to 1 if request is for configuration data. Otherwise, set to
       0.

     - S Bit

       Set to 1 if request is for running state data. Otherwise, set to
       0.

     - Request Type

       14-bits specifying the request type, encoded as follows:

        0x00   Request Data for specified pseudowire(s)
        0x01   Request Data for all pseudowires in specified service(s)
        0x3FFF Request All Data


     - Optional Sub-TLVs

       A set of zero or more TLVs, as follows:

       If the Request Type field is set to (0x00), then this field
       contains one or more PW ID TLV(s) or Generalized PW ID TLV(s). If
       the Request Type field is set to (0x01), then this field contains
       one or more Service Name TLV(s). If the Request Type field is set
       to (0x3FFF), then this field MUST be empty.  This document does
       not impose any restrictions on the length of the sub-TLVs.









Martini, et al.                                                [Page 46]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


7.1.6. PW-RED Synchronization Data TLV

   The PW-RED Synchronization Data TLV is used in the RG Application
   Data mesage. A pair of these TLVs is used by a device to delimit a
   set of TLVs that are sent in response to a PW-RED Synchronization
   Request TLV. The delimiting TLVs signal the start and end of the
   synchronization data, and associate the response with its
   corresponding request via the Request Number field.

   The PW-RED Synchronization Data TLVs are also used for unsolicited
   advertisements of complete PW-RED configuration and operational state
   data.  In this case, the Request Number field MUST be set to 0.

   This TLV has the following format:

    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=0x0018             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Request Number            |     Flags                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0018 for "PW-RED Synchronization Data TLV"

     - Length

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

     - Request Number

       2 octets. Unsigned integer identifying the Request Number from
       the "PW-RED Synchronization Request TLV" which solicited this
       synchronization data response.

     - Flags

       2 octets, response flags encoded as follows:





Martini, et al.                                                [Page 47]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


           0x00 Synchronization Data Start
           0x01 Synchronization Data End



7.2. Multi-chassis LACP (mLACP) Application TLVs

   This section discusses the ICCP TLVs for Ethernet attachment circuit
   redundancy using the multi-chassis LACP (mLACP) application.


7.2.1. mLACP Connect TLV

   This TLV is included in the RG Connect message to signal the
   establishment of mLACP 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=0x0030             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Protocol Version         |A|         Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Optional Sub-TLVs                          |
   ~                                                               ~
   |                                                               |
   +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0030 for "mLACP 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 48]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - A Bit

       Acknowledgement Bit. Set to 1 if the sender has received an mLACP
       Connect TLV from the recipient. Otherwise, set to 0.

     - Reserved

       Reserved for future use.

     - Optional Sub-TLVs

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


7.2.2. mLACP Disconnect TLV

   This TLV is used in an RG Disconnect Message to indicate that the
   connection for the mLACP 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=0x0031             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Optional Sub-TLVs                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0031 for "mLACP Disconnect TLV"

     - Length

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

     - Optional Sub-TLVs

       The only optional Sub-TLV defined for this version of the
       protocol is the "mLACP Disconnect Cause" TLV defined in Section
       7.2.2.1.




Martini, et al.                                                [Page 49]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


7.2.2.1. mLACP Disconnect Cause 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=0x003A             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Disconnect Cause String                  |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x003A for "mLACP Disconnect Cause TLV"

     - Length

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

     - Disconnect Cause String

       Variable length string specifying the reason for the disconnect.
       Used for network management.


7.2.3. mLACP System Config TLV

   The mLACP System Config TLV is sent in the RG Application Data
   message. This TLV announces the local node's LACP System Parameters
   to the RG peers.

    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=0x0032             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         System ID                             |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |         System Priority       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Node ID    |
   +-+-+-+-+-+-+-+-+



Martini, et al.                                                [Page 50]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0032 for "mLACP System Config TLV"

     - Length

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

     - System ID

       6 octets field encoding the System ID used by LACP as specified
       in [IEEE-802.1AX] section 5.3.2.

     - System Priority

       2 octets encoding the LACP System Priority as defined in [IEEE-
       802.1AX] section 5.3.2.

     - Node ID

       One octet, LACP node ID. Used to ensure that the LACP Port
       Numbers are unique across all devices in an RG. Valid values are
       in the range 0 - 7.  Uniqueness of the LACP Port Numbers across
       RG members is ensured by encoding the Port Numbers as follows:

           - Most significant bit always set to 1
           - The next 3 most significant bits set to Node ID
           - Remaining 12 bits freely assigned by the system



7.2.4. mLACP Aggregator Config TLV

   The mLACP Aggregator Config TLV is sent in the RG Application Data
   message.  This TLV is used to notify RG peers about the local
   configuration state of an aggregator.










Martini, et al.                                                [Page 51]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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=0x0036             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ROID                             |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Aggregator ID           |    MAC Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Actor Key               |    Member Ports Priority      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     | Agg Name Len  |    Aggregator Name            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                        ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0036 for "mLACP Aggregator Config TLV"

     - Length

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

     - ROID

       Defined in the 'ROID Encoding' section above.

     - Aggregator ID

       Two octets, LACP Aggregator Identifier as specified in [IEEE-
       802.1AX] section 5.4.6

     - MAC Address

       Six octets encoding the Aggregator MAC address.




Martini, et al.                                                [Page 52]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Actor Key

       Two octets, LACP Actor Key for the corresponding Aggregator, as
       specified in [IEEE-802.1AX] section 5.3.5.

     - Member Ports Priority

       Two octets, LACP administrative port priority associated with all
       interfaces bound to the Aggregator. This field is valid only when
       the "Flags" field has "Priority Set" asserted.

     - Flags

       Valid values are:

            -i. Synchronized (0x01)

                Indicates that the sender has concluded transmitting all
                Aggregator configuration information.

           -ii. Purge Configuration (0x02)

                Indicates that the Aggregator is no longer configured
                for mLACP operation.

          -iii. Priority Set (0x04)

                Indicates that the "Member Ports Priority" field is
                valid.

     - Agg Name Len

       One octet, length of the "Aggregator Name" field in octets.

     - Aggregator Name

       Aggregator name encoded in UTF-8 format, up to a maximum of 20
       octets.  Used for ease of management. The string does not include
       a terminating null character.


7.2.5. mLACP Port Config TLV

   The mLACP Port Config TLV is sent in the RG Application Data message.
   This TLV is used to notify RG peers about the local configuration
   state of a port.





Martini, et al.                                                [Page 53]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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=0x0033             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Port Number             |    MAC Address                |
   +-------------------------------+                               +
   |                                                               |
   +---------------------------------------------------------------+
   |       Actor Key               |     Port Priority             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Port Speed                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     | Port Name Len |         Port Name             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                        ...                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0033 for "mLACP Port Config TLV"

     - Length

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

     - Port Number

       Two octets, LACP Port Number for the corresponding interface as
       specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST
       be encoded with the Node ID as was discussed above.

     - MAC Address

       Six octets encoding the port MAC address.

     - Actor Key

       Two octets, LACP Actor Key for the corresponding interface, as
       specified in [IEEE-802.1AX] section 5.3.5.




Martini, et al.                                                [Page 54]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Port Priority

       Two octets, LACP administrative port priority for the
       corresponding interface, as specified in [IEEE-802.1AX] section
       5.3.4. This field is valid only when the "Flags" field has
       "Priority Set" asserted.

     - Port Speed

       Four octets integer encoding the port's current bandwidth in
       units of 1,000,000 bits per second. This field corresponds to the
       ifHighSpeed object of IF-MIB [RFC2863].

     - Flags

       Valid values are:

            -i. Synchronized (0x01)

                Indicates that the sender has concluded transmitting all
                member link port configurations for a given Aggregator.

           -ii. Purge Configuration (0x02)

                Indicates that the port is no longer configured for
                mLACP operation.

          -iii. Priority Set (0x04)

                Indicates that the "Port Priority" field is valid.

     - Port Name Len

       One octet, length of the "Port Name" field in octets.

     - Port Name

       This field corresponds to the ifName object of IF-MIB [RFC2863]
       encoded in UTF-8 format, and truncated to 20 octets. Port Name
       does not include a terminating null character.


7.2.6. mLACP Port Priority TLV

   The mLACP Port Priority TLV is sent in the RG Application Data
   message. This TLV is used by a device to either advertise its
   operational Port Priority to other members in the RG, or to
   authoritatively request that a particular member of an RG change its



Martini, et al.                                                [Page 55]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   port priority.

    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=0x0034             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OpCode               |          Port Number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Aggregator ID         |    Last Port Priority         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Current Port Priority      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0034 for "mLACP Port Priority TLV"

     - Length

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

     - OpCode

       Two octets identifying the operational code-point for the TLV,
       encoded as follows:

           0x00 Local Priority Change Notification
           0x01 Remote Request for Priority Change


     - Port Number

       2 octets field representing the LACP Port Number as specified in
       [IEEE-802.1AX] section 5.3.4. When the value of this field is 0,
       it denotes all ports bound to the Aggregator specified in the
       "Aggregator ID" field. When non-zero, the Port Number MUST be
       encoded with the Node ID as was discussed above.







Martini, et al.                                                [Page 56]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Aggregator ID

       Two octets, LACP Aggregator Identifier as specified in [IEEE-
       802.1AX] section 5.4.6

     - Last Port Priority

       Two octets, LACP port priority for the corresponding interface,
       as specified in [IEEE-802.1AX] section 5.3.4. For local ports,
       this field encodes the previous operational value of port
       priority. For remote ports, this field encodes the operational
       port priority last known to the PE via notifications received
       from its peers in the RG.

     - Current Port Priority

       Two octets, LACP port priority for the corresponding interface,
       as specified in [IEEE-802.1AX] section 5.3.4. For local ports,
       this field encodes the new operational value of port priority
       being advertised by the PE. For remote ports, this field
       specifies the new port priority being requested by the PE.


7.2.7. mLACP Port State TLV

   The mLACP Port State TLV is used in the RG Application Data message.
   This TLV is used by a device to report its LACP port status to other
   members in the RG.

    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=0x0035             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Partner System ID                        |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |     Partner System Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Partner Port Number       |     Partner Port Priority     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Partner Key             | Partner State |  Actor State  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Actor Port Number        |           Actor Key           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Selected     |  Port State   |        Aggregator ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Martini, et al.                                                [Page 57]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0035 for "mLACP Port State TLV"

     - Length

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

     - Partner System ID

       6 octets, the LACP Partner System ID for the corresponding
       interface, encoded as a MAC address as specified in [IEEE-
       802.1AX] section 5.4.2.2 item r.

     - Partner System Priority

       2 octets field specifying the LACP Partner System Priority as
       specified in [IEEE-802.1AX] section 5.4.2.2 item q.

     - Partner Port Number

       2 octets encoding the LACP Partner Port Number as specified in
       [IEEE-802.1AX] section 5.4.2.2 item u. The Port Number MUST be
       encoded with the Node ID as was discussed above.

     - Partner Port Priority

       2 octets field encoding the LACP Partner Port Priority as
       specified in [IEEE-802.1AX] section 5.4.2.2 item t.

     - Partner Key

       2 octets field representing the LACP Partner Key as defined in
       [IEEE-802.1AX] section 5.4.2.2 item s.

     - Partner State

       1 octet field encoding the LACP Partner State Variable as defined
       in [IEEE-802.1AX] section 5.4.2.2 item v.







Martini, et al.                                                [Page 58]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Actor State

       1 octet encoding the LACP Actor's State Variable for the port as
       specified in [IEEE-802.1AX] section 5.4.2.2 item m.

     - Actor Port Number

       2 octets field representing the LACP Actor Port Number as
       specified in [IEEE-802.1AX] section 5.3.4. The Port Number MUST
       be encoded with the Node ID as was discussed above.

     - Actor Key

       2 octet field encoding the LACP Actor Operational Key as
       specified in [IEEE-802.1AX] section 5.3.5.

     - Selected

       1 octet encoding the LACP 'Selected' variable, defined in [IEEE-
       802.1AX] section 5.4.8, as follows:

           0x00 SELECTED
           0x01 UNSELECTED
           0x02 STANDBY


     - Port State

       1 octet encoding the operational state of the port as follows:
           0x00 Up
           0x01 Down
           0x02 Administrative Down
           0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode)


     - Aggregator ID

       Two octets, LACP Aggregator Identifier to which this port is
       bound based on the outcome of the LACP selection logic.


7.2.8. mLACP Aggregator State TLV

   The mLACP Aggregator State TLV is used in the RG Application Data
   message. This TLV is used by a device to report its Aggregator status
   to other members in the RG.





Martini, et al.                                                [Page 59]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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=0x0037             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Partner System ID                        |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |     Partner System Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Partner Key              |         Aggregator ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Actor Key                |   Agg State   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0037 for "mLACP Aggregator State TLV"

     - Length

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

     - Partner System ID

       6 octets, the LACP Partner System ID for the corresponding
       interface, encoded as a MAC address as specified in [IEEE-
       802.1AX] section 5.4.2.2 item r.

     - Partner System Priority

       2 octets field specifying the LACP Partner System Priority as
       specified in [IEEE-802.1AX] section 5.4.2.2 item q.

     - Partner Key

       2 octets field representing the LACP Partner Key as defined in
       [IEEE-802.1AX] section 5.4.2.2 item s.

     - Aggregator ID

       Two octets, LACP Aggregator Identifier as specified in [IEEE-
       802.1AX] section 5.4.6



Martini, et al.                                                [Page 60]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


     - Actor Key

       2 octet field encoding the LACP Actor Operational Key as
       specified in [IEEE-802.1AX] section 5.3.5.

     - Agg State

       1 octet encoding the operational state of the Aggregator as
       follows:
           0x00 Up
           0x01 Down
           0x02 Administrative Down
           0x03 Test (e.g. IEEE 802.3ah OAM Intrusive Loopback mode)



7.2.9. mLACP Synchronization Request TLV

   The mLACP Synchronization Request TLV is used in the RG Application
   Data message. This TLV is used by a device to request from its peer
   to re-transmit configuration or operational state. The following
   information can be requested:

     - system configuration and/or state

     - configuration and/or state for a specific port

     - configuration and/or state for all ports with a specific LACP key

     - configuration and/or state for all mLACP ports

     - configuration and/or state for a specific aggregator

     - configuration and/or state for all aggregators with a specific
       LACP key

     - configuration and/or state for all mLACP aggregators

       The format of the TLV is as follows:












Martini, et al.                                                [Page 61]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


        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=0x0038             |    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Request Number           |C|S|    Request Type           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Port Number / Aggregator ID  |             Actor Key         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0038 for "mLACP Synchronization Request TLV"

     - Length

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

     - Request Number

       2 octets. Unsigned integer uniquely identifying the request. Used
       to match the request with a response. The value of 0 is reserved
       for unsolicited synchronization, and MUST NOT be used in the
       mLACP Synchronization Request TLV.

     - C Bit

       Set to 1 if request is for configuration data. Otherwise, set to
       0.

     - S Bit

       Set to 1 if request is for running state data. Otherwise, set to
       0.

     - Request Type

       14-bits specifying the request type, encoded as follows:







Martini, et al.                                                [Page 62]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


           0x00   Request System Data
           0x01   Request Aggregator Data
           0x02   Request Port Data
           0x3FFF Request All Data


     - Port Number / Aggregator ID

       2 octets. When Request Type field is set to 'Request Port Data',
       this field encodes the LACP Port Number for the requested port.
       When the Request Type field is set to 'Request Aggregator Data',
       this field encodes the Aggregator ID of the requested Aggregator.
       When the value of this field is 0, it denotes that all ports (or
       Aggregators), whose LACP Key is specified in the "Actor Key"
       field, are being requested.

     - Actor Key

       Two octets, LACP Actor key for the corresponding port or
       Aggregator. When the value of this field is 0 (and the Port
       Number/Aggregator ID field is 0 as well), it denotes that
       information for all ports or Aggregators in the system is being
       requested.


7.2.10. mLACP Synchronization Data TLV

   The mLACP Synchronization Data TLV is used in the RG Application Data
   message. A pair of these TLVs is used by a device to delimit a set of
   TLVs that are being transmitted in response to an mLACP
   Synchronization Request TLV. The delimiting TLVs signal the start and
   end of the synchronization data, and associate the response with its
   corresponding request via the 'Request Number' field.

   The mLACP Synchronization Data TLVs are also used for unsolicited
   advertisements of complete mLACP configuration and operational state
   data. The 'Request Number' field MUST be set to 0 in this case. For
   such unsolicited synchronization, the PE MUST advertise all system,
   Aggregator and port information as done during the initialization
   sequence.

   This TLV has the following format:









Martini, et al.                                                [Page 63]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


    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=0x0039             |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Request Number            |     Flags                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     - U and F Bits

       Both are set to 0.

     - Type

       set to 0x0039 for "mLACP Synchronization Data TLV"

     - Length

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

     - Request Number

       2 octets. Unsigned integer identifying the Request Number from
       the "mLACP Synchronization Request TLV" which solicited this
       synchronization data response.

     - Flags

       2 octets, response flags encoded as follows:

           0x00 Synchronization Data Start
           0x01 Synchronization Data End



8. LDP Capability Negotiation

   As requited in [RFC5561] 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=0x700      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |    Reserved   |  VER/Maj      |  Ver/Min      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Martini, et al.                                                [Page 64]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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

   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.

   It should be noted that the PW-RED application SHOULD NOT be enabled
   together with an AC Redundancy application for the same service
   instance.  This simplifies the operation of the multi-chassis



Martini, et al.                                                [Page 65]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   redundancy solution (Figure 1) and eliminates the possibility of
   deadlock conditions between the AC and PW redundancy mechanisms.



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 MUST send an
   "RG Connect" message with "PW-RED Connect TLV" to each PE that is a
   member of the same RG. The sending PE MUST set the A bit to 1 if it
   has already received a "PW-RED Connect TLV" from its peer; otherwise,
   the PE MUST set the A bit to 0. If a PE, that has sent the TLV with
   the A bit set to 0, receives a "PW-RED Connect TLV" from a peer, it
   MUST repeat its advertisement with the A bit set to 1. The PW-RED
   application connection is considered to be operational when both PEs
   have sent and received "PW-RED Connect TLVs" with the A bit set to 1.
   Once the application connection becomes operational, 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 a differing Protocol Version, it must follow the
   procedures outlined in the "Application Versioning" section above.

   When the PW-RED application is disabled on the device, or is
   unconfigured for the RG in question, the system MUST send an "RG
   Disconnect" message with "PW-RED Disconnect TLV".


9.1.2. Pseudowire Configuration Synchronization

   A system MUST 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 MUST be initiated when the PW-
   RED application connection first comes up. To that end, the system
   sends "RG Application Data" messages with "PW-RED Config TLVs" as
   part of an unsolicited synchronization. A PE MUST use a pair of "PW-
   RED Synchronization Data TLVs" to delimit the set of TLVs that are
   being sent as part of this unsolicited advertisement.

   In the case of a configuration change, a PE MUST re-advertise the
   most up to date information for the affected pseudowires.

   As part of the configuration synchronization, a PE advertises the
   ROID associated with the pseudowire. This is used to correlate the
   pseudowires that are protecting each other on different PEs. As well,



Martini, et al.                                                [Page 66]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   a PE advertises the configured PW redundancy mode. This can be one of
   the following four options: Master Mode, Slave Mode, Independent Mode
   or Independent Mode with Request Switchover. If the received
   redundancy mode does not match the locally configured mode for the
   same ROID, then the PE MUST respond with an "RG Notification Message"
   to reject the "PW-RED Config TLV". The PE MUST disable the associated
   local pseudowire until a satisfactory "PW-RED Config TLV" is received
   from the peer. This guarantees that device mis-configuration does not
   lead to network wide problems (e.g. by creating forwarding loops).
   The PE SHOULD also raise an alarm to alert the operator. If a PE
   receives a NAK TLV for an advertised "PW-RED Config TLV", it MUST
   disable the associated pseudowire and SHOULD raise an alarm to alert
   the operator.

   Furthermore, a PE advertises in its "PW-RED Config TLVs" a priority
   value that is used to determine the precedence of a given pseudowire
   to assume the Active role in a redundant setup. A PE also adverties a
   Service Name that is global in the context of an RG and is used to
   identify which pseudowires belong to the same service. Finally, a PE
   also advertises the pseudowire identifier as part of this
   synchronization.


9.1.3. Pseudowire Status Synchronization

   PEs, that are member of an RG, synchronize pseudowire status for the
   purpose of identifying, on a per ROID basis, which pseudowire will be
   actively used for forwarding and which pseudowire(s) will be placed
   in standby state.

   Synchronization of pseudowire status is done by sending the "PW-RED
   State TLV" whenever the pseudowire state changes on a PE.  This
   includes changes to the local end as well as the remote end of the
   pseudowire.

   A PE may request that its peer retransmit previously advertised PW-
   RED state. This is useful for instance when the PE is recovering from
   a soft failure. To request such retransmission, a PE MUST send a set
   of one or more "PW-RED Synchronization Request TLVs".

   A PE MUST respond to a "PW-RED Synchronization Request TLV" by
   sending the requested data in a set of one or more PW-RED TLVs
   delimited by a pair of "PW-RED Synchronization Data TLVs". The TLVs
   comprising the response MUST be ordered such that the Synchronization
   Response TLV with the "Synchronization Data Start" flag precedes the
   various other PW-RED TLVs encoding the requested data. These, in
   turn, MUST precede the Synchronization Data TLV with the
   "Synchronization Data End" flag. It is worth noting that the response



Martini, et al.                                                [Page 67]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   may span across multiple RG Application Data messages; however, the
   above TLV ordering MUST be retained across messages, and only a
   single pair of Synchronization Data TLVs must be used to delimit the
   response across all Application Data Messages.

   A PE MAY re-advertise its PW-RED state in an unsolicited manner. This
   is done by sending the appropriate config and state TLVs delimited by
   a pair of "PW-RED Synchronization Data TLVs" and using a 'Request
   Number' of 0.

   While a PE has a pending synchronization request for a pseudowire or
   a service, it SHOULD silently ignore all TLVs for said pseudowire or
   service that are received prior to the synchronization response and
   which carry the same type of information being requested. This saves
   the system from the burden of updating state that will ultimately be
   overwritten by the synchronization response. Note that TLVs
   pertaining to other pseudowires or services are to continue to be
   processed per normal in the interim.

   If a PE receives a synchronization request for a pseudowire or
   service that doesn't exist or is not known to the PE, then it MUST
   trigger an unsolicited synchronization of all pseudowire information
   (i.e. replay the initialization sequence).

   In the subsections that follow, we describe the details of pseudowire
   status synchronization for each of the PW redundancy modes defined in
   [RFC6870].


9.1.3.1. Independent Mode

   This section covers the operation in Independent Mode with or without
   Request Switchover capability.

   In this mode, the operator must ensure that for a given RO, the PW
   Priority values configured for all associated pseudowires on a given
   PE are collectively higher (or lower) than those configured on other
   PEs in the same RG. If this condition is not satisfied after the PEs
   have exchanged "PW-RED State TLVs", a PE MUST disable the associated
   pseudowire(s) and SHOULD raise an alarm to alert the operator. Note
   that the PW Priority MAY be the same as the PW Precedence defined in
   [RFC6870].

   For a given RO, after the all the PEs in an RG have exchanged their
   "PW-RED State TLVs", the PE with the best PW Priority (i.e. least
   numeric value) advertises Active preferential forwarding status in
   LDP on all its associated pseudowires. Whereas, all other PEs in the
   RG advertise Standby preferential forwarding status in LDP on their



Martini, et al.                                                [Page 68]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   associated pseudowires.

   If the service is VPWS, then only a single pseudowire per service
   will be selected for forwarding. This is the pseudowire that is
   independently advertised with Active preferential forwarding status
   on both endpoints, as described in [RFC6870].

   If the service is VPLS, then one or multiple pseudowires per service
   will be selected for forwarding. These are the pseudowires that are
   independently advertised with Active preferential forwarding status
   on both PW endpoints, as described in [RFC6870].


9.1.3.2. Master/Slave Mode

   In this mode, the operator must ensure that for a given RO, the PW
   Priority values configured for all associated pseudowires on a given
   PE are collectively higher (or lower) than those configured on other
   PEs in the same RG. If this condition is not satisfied after the PEs
   have exchanged "PW-RED State TLVs", a PE MUST disable the associated
   pseudowire(s) and SHOULD raise an alarm to alert the operator. Note
   that the PW Priority MAY be the same as the PW Precedence defined in
   [RFC6870]. In addition, the operator must ensure that, for a given
   RO, all the PEs in the RG are consistently configured as Master or
   Slave.

   In the context of a given RO, if the PEs in the RG are acting as
   Master, then the PE with the best PW Priority (i.e. least numeric
   value) advertises Active preferential forwarding status in LDP on
   only a single pseudowire, following the procedures in sections 5.2
   and 6.2 of [RFC6870]. Whereas, all the other pseudowires on other PEs
   in the RG are advertised with Standby preferential forwarding status
   in LDP.


9.1.4. PE Node Failure or Isolation

   When a PE node detects that a remote PE, that is member of the same
   RG, is no longer reachable (using the mechanisms of Section 5), 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 PW(s).








Martini, et al.                                                [Page 69]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


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. Remote PE Node Failure or Isolation

   When a PE node detects that a remote PE, that is member of the same
   RG, is no longer reachable (using the mechanisms of Section 5), 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. Local 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 ensure that its AC Redundancy mechanism will 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. Note that this works only in the
   case of dedicated interconnect (Sections 3.2.1 and 3.2.3) since ICCP
   will still have a path to the peer, even though the PE is isolated
   from the MPLS core network.







Martini, et al.                                                [Page 70]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


9.2.1.4. Determining Pseudowire State

   If the PEs in an RG are running an AC Redundancy application over
   ICCP, then the Independent Mode of PW Redundancy, as defined in
   [RFC6870], MUST be used. On a given PE, the Preferential 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 status is derived from the AC status 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.

   In this case, the PW-RED application is not used to synchronize PW
   status between PEs. Rather, the AC Redundancy application should
   synchronize AC status between PE, in order to establish which AC (and
   subsequently which PE) is Active or Standby for a given service. When
   that is determined, each PE will then derive its local PWs state
   according to the rules described above.  The Preferential Forwarding
   status bit, described in [RFC6870], is used to advertise PW status to
   the remote peers.



9.2.2. Multi-chassis LACP (mLACP) Application Procedures

   This section defines the procedures that are specific to the multi-
   chassis LACP (mLACP) application, which is applicable for Ethernet
   ACs.


9.2.2.1. Initial Setup

   When an RG is configured on a system and mLACP is enabled in that RG,
   the mLACP application MUST send an "RG Connect" message with "mLACP
   Connect TLV" to each PE that is member of the same RG. The sending PE



Martini, et al.                                                [Page 71]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   MUST set the A bit to 1 in the said TLV if it has received a
   corresponding "mLACP Connect TLV" from its peer PE; otherwise, the
   sending PE MUST set the A bit to 0. If a PE receives an "mLACP
   Connect TLV" from its peer after sending the said TLV with the A bit
   set to 0, it MUST resend the TLV with the A bit set to 1. A system
   considers the mLACP application connection to be operational when it
   has sent and received "mLACP Connect TLVs" with the A bit set to 1.
   When the mLACP application connection between a pair of PEs is
   operational, the two devices can start exchanging "RG Application
   Data" messages for the mLACP application. This involves having each
   PE advertise its mLACP configuration and operational state in an
   unsolicited manner. A PE SHOULD subscribe to the following order when
   advertising its mLACP state upon initial application connection
   setup:

     - Advertise system configuration
     - Advertise Aggregator configuration
     - Advertise port configuration
     - Advertise Aggregator state
     - Advertise port state

   A PE MUST use a pair of "mLACP Synchronization Data TLVs" to delimit
   the entire set of TLVs that are being sent as part of this
   unsolicited advertisement.

   If a system receives an "RG Connect" message with "mLACP Connect TLV"
   that has a differing Protocol Version, it MUST follow the procedures
   outlined in the "Application Versioning" section above.

   After the mLACP application connection has been established, every PE
   MUST communicate its system level configuration to its peers via the
   use of "mLACP System Config TLV". This allows every PE to discover
   the Node ID and the locally configured System ID and System Priority
   values of its peers.

   If a PE receives an "mLACP System Config TLV" from a remote peer
   advertising the same Node ID value as the local system, then the PE
   MUST respond with an "RG Notification Message" to reject the "mLACP
   System Config TLV". The PE MUST suspend the mLACP application until a
   satisfactory "mLACP System Config TLV" is received from the peer. It
   SHOULD also raise an alarm to alert the operator.  Furthermore, if a
   PE receives a NAK TLV for an "mLACP System Config TLV" that it has
   advertised, the PE MUST suspend the mLACP application and SHOULD
   raise an alarm to alert the network operator of potential device
   mis-configuration.

   If a PE receives an "mLACP System Config TLV" from a new peer
   advertising the same Node ID value as another existing peer with



Martini, et al.                                                [Page 72]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   which the local system has an established mLACP Application
   connection, then the PE MUST respond to the new peer with an "RG
   Notification Message" to reject the "mLACP System Config TLV" and
   MUST ignore the offending TLV.

   If the Node ID of a particular PE changes due to administrative
   configuration action, the PE MUST then inform its peers to purge the
   configuration of all previously advertised ports and/or aggregators,
   and MUST replay the initialization sequence by sending an unsolicited
   synchronization of: the system configuration, Aggregator
   configuration, port configuration, Aggregator state and port state.

   It is necessary for all PEs in an RG to agree upon the System ID and
   System Priority values to be used ubiquitously. To achieve this,
   every PE MUST use the values for the two parameters that are supplied
   by the PE with the numerically lowest value (among RG members) of
   System Aggregation Priority.  This guarantees that the PEs always
   agree on uniform values, which yield the highest System Priority.

   When the mLACP application is disabled on the device, or is
   unconfigured for the RG in question, the system MUST send an "RG
   Disconnect" message with "mLACP Disconnect TLV".


9.2.2.2. mLACP Aggregator and Port Configuration

   A system MUST synchronize the configuration of its mLACP enabled
   Aggregators and ports with other RG members. This is achieved via the
   use of "mLACP Aggregator Config TLVs" and "mLACP Port Config TLVs",
   respectively. An implementation MUST advertise the configuration of
   Aggregators prior to advertising the configuration of any of their
   associated member ports.

   The PEs in an RG MUST all agree on the MAC address to be associated
   with a given Aggregator. It is possible to achieve this via
   consistent configuration on member PEs. However, in order to protect
   against possible misconfiguration, a system MUST use, for any given
   Aggregator, the MAC address supplied by the PE with the numerically
   lowest System Aggregation Priority in the RG.

   A system that receives an "mLACP Aggregator Config TLV" with an ROID
   to Key association that is different from its local association MUST
   reject the corresponding TLV and disable the Aggregator with the same
   ROID. Furthermore, it SHOULD raise an alarm to alert the operator.
   Similarly, a system that receives a NAK TLV in response to a
   transmitted "mLACP Aggregator Config TLV" MUST disable the associated
   Aggregator and SHOULD raise an alarm to alert the network operator.




Martini, et al.                                                [Page 73]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   A system MAY enforce a restriction that all ports that are to be
   bundled together on a given PE share the same Port Priority value. If
   so, the system MUST advertise this common priority in the "mLACP
   Aggregator Config TLV" and assert the "Priority Set" flag in such
   TLV. Furthermore, the system in this case MUST NOT advertise
   individual Port Priority values in the associated "mLACP Port Config
   TLVs" (i.e. the "Priority Set" flag in these TLVs should be 0).

   A system MAY support individual Port Priority values to be configured
   on ports that are to be bundled together on a PE. If so, the system
   MUST advertise the individual Port Priority values in the appropriate
   "mLACP Port Config TLVs", and MUST NOT assert the "Priority Set" flag
   in the corresponding "mLACP Aggregator Config TLV".

   When the configurations of all ports for member links associated with
   a given Aggregator have been sent by a device, it asserts that fact
   by setting the "Synchronized" flag in the last port's "mLACP Port
   Config TLV". If an Aggregator doesn't have any candidate member ports
   configured, this is indicated by asserting the "Synchronized" flag in
   its "mLACP Aggregator Config TLV".

   Furthermore, for a given port/Aggregator, an implementation MUST
   advertise the port/Aggregator configuration prior to advertising its
   state (via the "mLACP Port State TLV" or "mLACP Aggregator State
   TLV"). If a PE receives an "mLACP Port State TLV" or "mLACP
   Aggregator State TLV" for a port or Aggregator that it had not
   learned of before via an appropriate Port or Aggregator Config TLV,
   then the PE MUST request synchronization of the configuration and
   state of all mLACP ports as well as all mLACP Aggregators from its
   respective peer. If during a synchronization (solicited or
   unsolicited), a PE receives a State TLV for a port or Aggregator that
   it has not learned of before, then the PE MUST send a NAK TLV for the
   offending TLV. The PE MUST NOT request re-synchronization in this
   case.

   When mLACP is unconfigured on a port/Aggregator, a PE MUST send a
   "Port/Aggregator Config TLV" with the "Purge Configuration" flag
   asserted. This allows receiving PEs to purge any state maintained for
   the decommissioned port/Aggregator. If a PE receives a
   "Port/Aggregator Config TLV" with the "Purge Configuration" flag
   asserted, and the PE is not maintaining any state for that
   port/Aggregator, then it MUST silently discard the TLV.


9.2.2.3. mLACP Aggregator and Port Status Synchronization

   PEs within an RG need to synchronize their state-machines for proper
   mLACP operation with a multi-homed device. This is achieved by having



Martini, et al.                                                [Page 74]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   each system advertise its Aggregators and ports running state in
   "mLACP Aggregator State TLVs" and "mLACP Port State TLVs",
   respectively. Whenever any LACP parameter for an Aggregator or a
   port, whether on the Partner (i.e. multi-homed device) or the Actor
   (i.e. PE) side, is changed a system MUST transmit an updated TLV for
   the affected Aggregator and/or port. Moreover, when the
   administrative or operational state of an Aggregator or port changes,
   the system MUST transmit an updated Aggregator or port state TLV to
   its peers.

   If a PE receives an Aggregator or port state TLV where the 'Actor
   Key' doesn't match what was previously received in a corresponding
   Aggregator or port config TLV, the PE MUST then request
   synchronization of the configuration and state of the affected
   Aggregator or port. If such a mismatch occurs between the config and
   state TLVs as part of a synchronization (solicited or unsolicited),
   then the PE MUST send a NAK TLV for the state TLV. Furthermore, if a
   PE receives a port state TLV with the 'Aggregator ID' set to a value
   that doesn't map to some Aggregator that the PE had learned of via a
   previous Aggregator config TLV, then the PE MUST request
   synchronization of the configuration and state of all Aggregators and
   ports. If the above anomaly occurs during a synchronization, then the
   PE MUST send a NAK TLV for the offending port state TLV.

   A PE MAY request that its peer retransmit previously advertised
   state. This is useful for example when the PE is recovering from a
   soft failure and attempting to relearn state. To request such
   retransmissions, a PE MUST send a set of one or more "mLACP
   Synchronization Request TLVs".

   A PE MUST respond to an "mLACP Synchronization Request TLV" by
   sending the requested data in a set of one or more mLACP TLVs
   delimited by a pair of "mLACP Synchronization Data TLVs". The TLVs
   comprising the response MUST be ordered in the RG Application Data
   message(s) such that the Synchronization Response TLV with the
   "Synchronization Data Start" flag precedes the various other mLACP
   TLVs encoding the requested data. These, in turn, MUST precede the
   Synchronization Data TLV with the "Synchronization Data End" flag.
   Note that the response may span across multiple RG Application Data
   messages, for example when MTU limits are exceeded; however, the
   above ordering MUST be retained across messages, and only a single
   pair of Synchronization Data TLVs MUST be used to delimit the
   response across all Application Data Messages.

   A PE device MAY re-advertise its mLACP state in an unsolicited
   manner. This is done by sending the appropriate Config and State TLVs
   delimited by a pair of "mLACP Synchronization Data TLVs" and using a
   'Request Number' of 0.



Martini, et al.                                                [Page 75]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   While a PE has a pending synchronization request for a system,
   Aggregator or port, it SHOULD silently ignore all TLVs for said
   system, Aggregator or port that are received prior to the
   synchronization response and which carry the same type of information
   being requested.  This saves the system from the burden of updating
   state that will utlimately be overwritten by the synchronization
   response. Note that TLVs pertaining to other systems, Aggregators or
   ports are to continue to be processed per normal in this case.

   If a PE receives a synchronization request for an Aggregator, port or
   Key that doesn't exist or is not known to the PE, then it MUST
   trigger an unsolicited synchronization of all system, Aggregator and
   port information (i.e. replay the initialization sequence).

   If a PE learns, as part of a synchronization operation from its peer,
   that the latter is advertising a Node ID value which is different
   from the value previously advertised, then the PE MUST purge all
   port/aggregator data previously learnt from that peer prior to the
   last synchronization.


9.2.2.4. Failure and Recovery

   When a PE that is active for a multi-chassis link aggregation group
   encounters a core isolation fault, it SHOULD attempt to fail-over to
   a peer PE which hosts the same RO. The default fail-over procedure is
   to have the failed PE bring down the link(s) towards the multi-homed
   CE (e.g. by bringing down the line-protocol). This will cause the CE
   to fail-over to the other member link(s) of the bundle that are
   connected to the other PE(s) in the RG. Other procedures for
   triggering fail-over are possible, and are outside the scope of this
   document.

   Upon recovery from a previous fault, a PE MAY reclaim active role for
   a multi-chassis link aggregation group if configured for revertive
   protection.  Otherwise, the recovering PE may assume standby role
   when configured for non-revertive protection. In the revertive
   scenario, a PE SHOULD assume active role within the RG by sending an
   "mLACP Port Priority TLV" to the currently active PE, requesting that
   the latter change its port priority to a value that is lower (i.e.
   numerically larger) for the Aggregator in question.

   If a system is operating in a mode where different ports of a bundle
   are configured with different Port Priorities, then the system MUST
   NOT advertise or request change of Port Priority values for
   aggregated ports collectively (i.e. by using a 'Port Number' of 0 in
   the "mLACP Port Priority TLV"). This is to avoid ambiguity in the
   interpretation of the 'Last Port Priority' field.



Martini, et al.                                                [Page 76]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   If a PE receives an "mLACP Port Priority TLV" requesting a priority
   change for a port or Aggregator that is not local to the device, then
   the PE MUST re-advertise the local configuration of the system, as
   well as the configuration and state of all its mLACP ports and
   Aggregators.

   If a PE receives an "mLACP Port Priority TLV" in which the remote
   system is advertising priority change for a port or Aggregator that
   the local PE had not learned of before via an appropriate Port or
   Aggregator Config TLV, then the PE MUST request synchronization of
   the configuration and state of all mLACP ports as well as all mLACP
   Aggregators from its respective peer.


10. Security Considerations

   ICCP SHOULD only be used in well managed and highly monitored
   networks. It ought not be deployed on or over the public Internet.
   The ICCP protocol is not intended to be applicable when the
   redundancy group spans PE in different administrative domains.

   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. In particular, ICCP implementations MUST provide a
   mechanism to select to which LDP peers the ICCP capability will be
   advertised, and from which LDP peers the ICCP messages will be
   accepted. Therefore, an incoming ICCP connection request MUST NOT be
   accepted unless its source IP address is known to be the source of an
   "eligible" ICCP peer. The set of eligible peers could be pre-
   configured (either as a list of IP addresses, or as a list of
   address/mask combinations), or it could be discovered dynamically via
   some secure discovery protocol.  The TCP Authentication Option (TCP-
   AO), as defined in [RFC5925], SHOULD be used. This provides integrity
   and authentication for the ICCP messages and eliminates the
   possiblity of source address spoofing. However, for backwards
   compatibility and/or to accommodate the ease of migration, the LDP
   MD5 authentication key option, as described in section 2.9 of
   [RFC5036] MAY be used instead.

   The security framework and considerations for MPLS in general, and
   LDP in particular, described in [RFC5920] apply to this document.
   Moreover, the recommendations of [RFC6952] and mechanisms of [LDP-
   CRYPTO] aimed at addressing LDP's vulnerabilities are applicable as
   well.

   Furthermore, activitiy on the attachment ciruits may cause security
   threats or be exploited to create denial of service attackes. For



Martini, et al.                                                [Page 77]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   example, a malicious CE implementation may trigger continuously
   variying LACP messages that lead to excessive ICCP exchanges. Also,
   excessive link bouncing of the attachment circuits may lead to the
   same effect. Similar arguments apply to the inter-PE MPLS links.
   Implementations SHOULD provide mechanisms to perform control-plane
   policing and mitigate such types of attacks.


11. Manageability Considerations

   Implementations SHOULD generally minimize the number of parameters
   required to configure ICCP, as this contributes to the ease of use.
   Implementations SHOULD allow the user to control the RGID via
   configuration, as this is required to support flexible grouping of
   PEs in RGs. Furthermore, implementations SHOULD provide mechanisms to
   troubleshoot the correct operation of ICCP, this includes providing
   mechanisms to diagnose ICCP as well as Application connections.
   Implementations MUST provide a means for the user to indicate the IP
   addresses of remote PEs that are to be members of a given RG.
   Automatic discovery of RG membership MAY be supported, and is outside
   the scope of this specification.


12. IANA Considerations

12.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
        0x0704-0x070F   Reserved for future ICCP use


12.2. TLV TYPE NAME SPACE

   This document uses 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
       0x700       ICCP capability TLV.





Martini, et al.                                                [Page 78]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


12.3. ICC RG Parameter Type Space

   IANA needs to set up a registry of "ICC RG parameter type", to be
   added to the list of "Pseudowire Name Spaces (PWE3)" registries. ICC
   RG parameter types are 14-bit values. Parameter Type values 1 through
   0x003A are specified in this document, Parameter Type values 0x003B
   through 0x1FFF are to be assigned by IANA, using the "Expert Review"
   policy defined in [RFC5226]. Parameter Type values 0x2000 through
   0x2FFF, 0x3FFF, and 0 are to be allocated using the IETF consensus
   policy defined in [RFC5226]. 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 [RFC5226].

   Initial ICC parameter type space value allocations are specified
   below:

   Parameter Type Description
   -------------- ---------------------------------
   0x0001         ICC Sender Name
   0x0002         NAK TLV
   0x0003         Requested Protocol Version TLV
   0x0004         Disconnect Code TLV
   0x0005         ICC RG ID TLV
   0x0006-0x000F  Reserved
   0x0010         PW-RED Connect TLV
   0x0011         PW-RED Disconnect TLV
   0x0012         PW-RED Config TLV
   0x0013         Service Name TLV
   0x0014         PW ID TLV
   0x0015         Generalized PW ID TLV
   0x0016         PW-RED State TLV
   0x0017         PW-RED Synchronization Request TLV
   0x0018         PW-RED Synchronization Data TLV
   0x0019         PW-RED Disconnect Cause TLV
   0x001A-0x002F  Reserved
   0x0030         mLACP Connect TLV
   0x0031         mLACP Disconnect TLV
   0x0032         mLACP System Config TLV
   0x0033         mLACP Port Config TLV
   0x0034         mLACP Port Priority TLV
   0x0035         mLACP Port State TLV
   0x0036         mLACP Aggregator Config TLV
   0x0037         mLACP Aggregator State TLV
   0x0038         mLACP Synchronization Request TLV
   0x0039         mLACP Synchronization Data TLV
   0x003A         mLACP Disconnect Cause TLV




Martini, et al.                                                [Page 79]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


12.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
   ------------- -----   ----------------------
   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
   0x00010007      0     ICCP Administratively Disabled
   0x00010010      0     ICCP RG Removed
   0x00010011      0     ICCP Application Removed from RG


13. Acknowledgments

   The authors wish to acknowledge the important contributions of Dennis
   Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami
   Boutros, Neil Ketley and Mark Christopher Sains.

   The authors also thank Daniel Cohn, Lizhong Jin and Ran Chen for the
   valuable input, discussions and comments.


14. Normative References

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

   [RFC5561] "LDP Capabilities", RFC5561, July  2009.

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

   [IEEE-802.1AX] IEEE Std. 802.1AX-2008, "IEEE Standard for Local and
        metropolitan area networks- Link Aggregation", IEEE Computer
        Society, November 2008.

   [RFC2863] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB",
        rfc2863, June 2000.





Martini, et al.                                                [Page 80]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   [RFC6870] Praveen Muley, Mustapha Aissaoui, "Pseudowire
        Preferential Forwarding Status Bit", RFC 6870,
        February 2013.

   [RFC5920] L. Fang, "Security Framework for MPLS and GMPLS Networks",
        rfc5920, July 2010.

   [RFC6952] M. Jethanandani et al., "Analysis of BGP, LDP, PCEP, and
        MSDP Issues According to the Keying and Authentication for Routing
        Protocols (KARP) Design Guide", rfc6952, May 2013.

   [RFC5925] J. Touch et al., "The TCP Authentication Option", RFC 5925,
        June 2010.

15. Informative References

   [RFC2922] Bierman & Jones, "Physical Topology MIB",
        RFC2922, September 2000.

   [RFC5880] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
        RFC5880, June 2010

   [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
        IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008

   [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

   [LDP-CRYPTO] L. Zheng et al., "LDP Hello Cryptographic Autentication",
        draft-ietf-mpls-ldp-hello-crypto-auth-02, work in progress,
        August 2013.


16. Author's Addresses


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










Martini, et al.                                                [Page 81]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014



   Samer Salam
   Cisco Systems, Inc.
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1
   Canada
   e-mail: ssalam@cisco.com


   Ali Sajassi
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: sajassi@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


   Satoru Matsushima
   Softbank Telecom
   1-9-1, Higashi-Shinbashi, Minato-ku
   Tokyo 105-7313, JAPAN
   e-mail: satoru.matsushima@gmail.com


   Thomas Nadeau
   Brocade
   e-mail: tnadeau@brocade.com



Copyright Notice

   Copyright (c) 2014 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



Martini, et al.                                                [Page 82]






Internet Draft        draft-ietf-pwe3-iccp-16.txt         March 27, 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.





































Martini, et al.                                                [Page 83]