tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7275

 
 
 

Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy

Part 2 of 4, p. 11 to 35
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 11 
4.  ICC LDP Protocol Extension Specification

   To address the requirements identified in the previous section, ICCP
   is modeled to comprise 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

Top      Up      ToC       Page 12 
        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 interoperability without placing
        any unnecessary constraints on internal design specifics.

    ii. Inter-Chassis Communication (ICC) Layer: This layer implements
        the common set of services that 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 interconnect.

4.1.  LDP ICCP Capability Advertisement

   When an RG is enabled on a particular PE, an LDP session to every
   remote PE in that RG MUST be created, if one does not already exist.
   The capability of supporting ICCP MUST then be advertised to all of
   those LDP peers in that RG.  This is achieved by using the methods
   described in [RFC5561] and advertising the "ICCP 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 advertisements, 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 devices 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 of expecting the corresponding "RG Connect" message (or

Top      Up      ToC       Page 13 
   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 (Negative Acknowledgement
   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.

   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:

   - NONEXISTENT: 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 capability information has not yet
     been exchanged between them.

Top      Up      ToC       Page 14 
   - CAPSENT: This state indicates that an LDP session exists between
     the PEs and that the local PE has advertised 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 advertised 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.

Top      Up      ToC       Page 15 
                  ICCP Connection State Transition Table

    STATE         EVENT                                     NEW STATE
   --------------------------------------------------------------------
    NONEXISTENT   LDP session established                   INITIALIZED

    INITIALIZED   Transmit LDP ICCP capability              CAPSENT

                  Receive LDP ICCP capability               CAPREC
                     Action: Transmit LDP ICCP capability

                  LDP session torn down                     NONEXISTENT

    CAPSENT       Receive LDP ICCP capability               CAPREC

                  LDP session torn down                     NONEXISTENT

    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                     NONEXISTENT

    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                     NONEXISTENT

    OPERATIONAL   Receive acceptable RG Disconnect message  CAPREC

                  Transmit RG Disconnect message            CAPREC

                  LDP session torn down                     NONEXISTENT

Top      Up      ToC       Page 16 
                 ICCP Connection State Transition Diagram

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

Top      Up      ToC       Page 17 
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) that are being
   protected in a redundant setup.  These are referred to as Redundant
   Objects (ROs).  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 the Redundant Object ID (ROID), MUST match
   between RG members for the protected object in question; this 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 the 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 Connect TLV" (carried in an "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 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.

Top      Up      ToC       Page 18 
   When a PE receives such a rejection notification, it MUST stop
   attempting to bring up the Application Connection until it receives a
   new Application Connection request from the remote PE.  This is done
   by responding to the incoming "RG Connect" message (carrying an
   "Application Connect TLV") with an appropriate "RG Connect" message
   (carrying a corresponding "Application 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 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, 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 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 Connect TLV" with a
     version number that is lower than its own, it MAY respond with an
     RG Connect that has an "Application 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 supply the version that is
     supported.  This allows an application to operate in either
     backwards-compatible or incompatible mode.

   - If an application receives an "Application 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.

Top      Up      ToC       Page 19 
4.4.2.  Application Connection State Machine

   A PE maintains one 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:

   - NONEXISTENT: 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 state transition diagram follow.

            ICCP Application Connection State Transition Table

     STATE          EVENT                                  NEW STATE
   -------------------------------------------------------------------
     NONEXISTENT    ICCP connection established            RESET

     RESET          ICCP connection torn down              NONEXISTENT

                    Transmit Application Connect TLV       CONNSENT

                    Receive Application Connect TLV        CONNREC

                    Receive any other Application TLV      RESET
                      Action: Transmit NAK TLV

Top      Up      ToC       Page 20 
     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              NONEXISTENT

     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              NONEXISTENT

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

                    Receive any other Application TLV      RESET
                      Action: Transmit NAK TLV

                    ICCP connection torn down              NONEXISTENT

     OPERATIONAL    Receive Application Disconnect TLV     RESET

                    Transmit Application Disconnect TLV    RESET

                    ICCP connection torn down              NONEXISTENT

Top      Up      ToC       Page 21 
           ICCP Application Connection State Transition Diagram

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

Top      Up      ToC       Page 22 
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 lossless 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 a "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 that 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 that a fairly large
   amount of RG information be exchanged 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,
   initiating a separate TCP/IP session between the two LDP speakers may
   be required.

   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 [RFC5036] and this document.

5.  ICCP PE Node Failure / Isolation Detection Mechanism

   ICCP provides its client applications a notification when a remote PE
   that is a member of the RG is no longer reachable.  In the case of a
   dedicated interconnect, this indicates that the remote PE node has
   failed, whereas in the case of a shared interconnect this indicates
   that the remote PE node has either failed or become isolated from the
   MPLS network.  This information is used by the client applications to

Top      Up      ToC       Page 23 
   trigger failover according to the procedures of the redundancy
   protocol employed on the AC and PW.  To that end, ICCP does not
   define its own Keep-Alive mechanism for the 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:

   - Bidirectional Forwarding Detection (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 technique 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 example, that the remote PE could encounter a local
   event that would lead to resetting the LDP session, while the PE node
   would remain operational for traffic forwarding purposes.

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, stateful message delivery, as well
   as capability negotiation between PEs.  LDP offers all of 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 0x0700 to 0x070F will be
   used for ICCP.

Top      Up      ToC       Page 24 
   Message types have been allocated by IANA; see Section 12 below for
   details.

6.1.1.  ICC Header

   Every ICCP message comprises an ICC-specific LDP Header followed by
   message data.  The format of the ICC Header 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|   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.
     Subsequent sections that define messages specify a value for the
     U-bit.

   - Message Type

     Identifies the type of the ICCP message.  Must be in the range
     0x0700 to 0x070F.

Top      Up      ToC       Page 25 
   - Message Length

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

   - Message ID

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

   - ICC RG ID TLV

     A TLV of type 0x0005, length 4, containing a 4-octet unsigned
     integer designating the Redundancy Group of which the sending
     device is a member.  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.

Top      Up      ToC       Page 26 
6.1.2.  ICC Parameter Encoding

   The generic format of an ICC parameter 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                |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   TLV(s)                                                      |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - U-bit

     Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
     (=0), a notification MUST be returned to the message originator and
     the entire message MUST be ignored; if U is set (=1), the unknown
     TLV MUST be silently ignored and the rest of the message processed
     as if the unknown TLV did not exist.  Subsequent sections 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 LDP message; if F is set (=1), the unknown TLV is
     forwarded with the LDP message.  Subsequent sections 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

     14 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.  Contents will vary according to
     the message type.

Top      Up      ToC       Page 27 
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) that 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                             |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where the ROID is an 8-octet 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 Connect TLV"
   signals establishment of the ICCP RG connection, whereas an "RG
   Connect" message with a valid "Application 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 for each
   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
   a 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 a member of multiple RGs, it MUST send separate "RG
   Connect" messages for each RG even if the receiving device(s) happens
   to be the same.

Top      Up      ToC       Page 28 
   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 Connect TLV"

   The currently defined "Application Connect TLVs" are as follows:

   - PW-RED Connect TLV (Section 7.1.1)

   - mLACP Connect TLV (Section 7.2.1)

   The details of these TLVs are discussed in Section 7.

   The "RG Connect" message can contain zero or one "Application Connect
   TLV".

6.2.1.  ICC Sender Name TLV

   The "ICC Sender Name TLV" carries the hostname of the sender, encoded
   in UTF-8 [RFC3629] format.  This is used primarily for the 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 the ICC parameter name space).

   - Length

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

Top      Up      ToC       Page 29 
   - Sender Name

     An administratively assigned name of the sending device, encoded in
     UTF-8 format 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 a 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 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|   Message Type = 0x0701     |      Message Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Message ID                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = 0x0005 (ICC RG ID)   |           Length=4            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     ICC RG ID                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Disconnect Code TLV                        |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Optional Application Disconnect TLV              |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Optional Parameter TLVs                     |
     +                                                               +
     |                                                               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - U-bit

     U=0

   - Message Type

     The message type for the "RG Disconnect" message is set to 0x0701.

Top      Up      ToC       Page 30 
   - Length

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

   - Message ID

     Defined in Section 6.1.1 above.

   - ICC RG ID

     Defined in Section 6.1.1 above.

   - 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-bit and F-bit

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

Top      Up      ToC       Page 31 
   - Optional Application Disconnect TLV

     Zero or one "Application Disconnect TLV" (defined in Sections 7.1.2
     and 7.2.2).  If the "RG Disconnect" message has a status code of
     "RG Removed", then it MUST NOT contain any "Application 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 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.

   - 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
   TLVs 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 as follows:

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

   ii. Notification Message TLVs

   The currently defined Notification message TLVs are as follows:

    i. ICC Sender Name TLV

   ii. Negative Acknowledgement (NAK) TLV

Top      Up      ToC       Page 32 
6.4.1.  Notification Message TLVs

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

   The "NAK TLV" is defined as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F|       Type = 0x0002       |    Length                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      ICCP Status Code                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Rejected Message ID                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Optional TLV(s)                              |
     +                                                               +
     |                                                               |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - U-bit and F-bit

     Both 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 as follows:

       i. Unknown ICCP 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.

Top      Up      ToC       Page 33 
      ii. ICCP Connection Count Exceeded (0x00010002)

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

     iii. ICCP 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. ICCP 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 ICCP 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. ICCP Rejected Message (0x00010006)

          This is used to reject an "RG Application Data" message, or
          one or more TLVs 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.

Top      Up      ToC       Page 34 
     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, a 4-octet value that identifies the peer message to
     which the "NAK TLV" refers.  If zero, no specific peer message is
     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 or TLVs that
     were rejected.  If the entire message is rejected, all of 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-bit and F-bit

       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.

Top      Up      ToC       Page 35 
     - Connection Reference

       Set to the "Type" field of the "Application 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.

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 as follows:

    i. ICC Header with Message type = "RG Application Data Message"
       (0x0703)

   ii. Application-specific TLVs

   The details of these TLVs are discussed in Section 7.  All
   application-specific TLVs in one "RG Application Data" message MUST
   belong to a single application but MAY reference different ROs.



(page 35 continued on part 3)

Next RFC Part