tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7275

 
 
 

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

Part 4 of 4, p. 65 to 83
Prev RFC Part

 


prevText      Top      Up      ToC       Page 65 
8.  LDP Capability Negotiation

   As required 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 = 0x0700   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S| Reserved    |    Reserved   |  Ver/Maj      |  Ver/Min      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - 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 listed in Section 12 below.

   - S-bit

     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 ICCP.  This document specifies 1.0,
     and so this field is set to 1.

   - Ver/Min

     The minor version revision of ICCP.  This document specifies 1.0,
     and so this field is set to 0.

Top      Up      ToC       Page 66 
   ICCP capability is advertised to an 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
   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 a "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 a "PW-RED Connect
   TLV" that has a different Protocol Version, it must follow the
   procedures outlined in Section 4.4.1 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 a "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"

Top      Up      ToC       Page 67 
   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.  A PE
   also 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
   misconfiguration 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 advertises
   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 members 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.

Top      Up      ToC       Page 68 
   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 a 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 may span 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
   that 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 procedures 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].

Top      Up      ToC       Page 69 
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 as defined
   in [RFC6870].

   For a given RO, after all of 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 of its associated pseudowires, whereas all other PEs in
   the RG advertise standby Preferential Forwarding status in LDP on
   their 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 as defined
   in [RFC6870].  In addition, the operator must ensure that for a given
   RO all of 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

Top      Up      ToC       Page 70 
   only a single pseudowire, following the procedures in Sections 5.2
   and 6.2 of [RFC6870], whereas all of 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 a member of the same
   RG is no longer reachable (using the mechanisms described in
   Section 5), the local PE determines 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).

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 a member of the same
   RG is no longer reachable (using the mechanisms described in
   Section 5), the local PE determines 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.

Top      Up      ToC       Page 71 
9.2.1.3.  Local PE Isolation

   When a PE node detects that it 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.

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.,
     Virtual Switch Instance (VSI) [RFC4026]).  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 PEs, 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 PW's
   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.

Top      Up      ToC       Page 72 
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 an
   "mLACP Connect TLV" to each PE that is a member of the same RG.  The
   sending PE MUST set the A-bit to 1 in 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 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 use the following sequence 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 an "mLACP Connect
   TLV" that has a different Protocol Version, it MUST follow the
   procedures outlined in Section 4.4.1 above.

Top      Up      ToC       Page 73 
   After the mLACP Application Connection has been established, every PE
   MUST communicate its system-level configuration to its peers via the
   use of the "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
   misconfiguration.

   If a PE receives an "mLACP System Config TLV" from a new peer
   advertising the same Node ID value as another existing peer with
   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 that 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 an "mLACP Disconnect TLV".

Top      Up      ToC       Page 74 
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.

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

Top      Up      ToC       Page 75 
   TLV").  If a PE receives an "mLACP Port State TLV" or "mLACP
   Aggregator State TLV" for a port or Aggregator that it had not
   previously learned via an appropriate "Port Config TLV" 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.  During a synchronization
   (solicited or unsolicited), if a PE receives a "State TLV" for a port
   or Aggregator that it has not learned before, then the PE MUST send a
   "NAK TLV" for the offending TLV.  The PE MUST NOT request
   resynchronization 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 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) side 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 Config TLV" 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 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".

Top      Up      ToC       Page 76 
   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 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.

   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 that 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 systems, Aggregators,
   or ports are to continue to be processed per normal procedures 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 that is different from
   the value previously advertised, then the PE MUST purge all
   Port/Aggregator data previously learned from that peer prior to the
   last synchronization.

Top      Up      ToC       Page 77 
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 that hosts the same RO.  The default failover procedure is
   to have the failed PE bring down the link or links 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 or links of the
   bundle that are connected to the other PE(s) in the RG.  Other
   procedures for triggering failover are possible; such procedures are
   outside the scope of this document.

   Upon recovery from a previous fault, a PE MAY reclaim the active role
   for a multi-chassis link aggregation group if configured for
   revertive protection.  Otherwise, the recovering PE may assume the
   standby role when configured for non-revertive protection.  In the
   revertive scenario, a PE SHOULD assume the 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 changes 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.

   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 of 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 previously learned via an appropriate "Port
   Config TLV" 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.

Top      Up      ToC       Page 78 
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.
   ICCP is not intended to be applicable when the Redundancy Group spans
   PEs 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
   preconfigured (as a list of either IP addresses or 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 possibility
   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, as 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, activity on the attachment circuits may cause security
   threats or be exploited to create denial-of-service attacks.  For
   example, a malicious CE implementation may trigger continuously
   varying 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 these types of attacks.

Top      Up      ToC       Page 79 
11.  Manageability Considerations

   Implementations SHOULD generally minimize the number of parameters
   required to configure ICCP in order to help make ICCP easier to 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 connections 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; this topic 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 maintains the
   "Message Type Name Space" registry as defined by [RFC5036].  The
   following values have been assigned:

        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 maintains the "TLV Type
   Name Space" registry as defined by [RFC5036].  The following value
   has been assigned:

        TLV Type      Description
        --------      -------------------
        0x0700        ICCP capability TLV

Top      Up      ToC       Page 80 
12.3.  ICC RG Parameter Type Space

   IANA has created a registry called "ICC RG Parameter Types", within
   the "Pseudowire Name Spaces (PWE3)" registry.  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 Review" 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

Top      Up      ToC       Page 81 
12.4.  Status Code Name Space

   This document uses several new Status codes.  IANA maintains the
   "Status Code Name Space" registry as defined by [RFC5036].  The
   following values have been assigned; 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
   their valuable input, discussions, and comments.

14.  References

14.1.  Normative References

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

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, October 2007.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447, April 2006.

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

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

   [RFC6870]  Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire
              Preferential Forwarding Status Bit", RFC 6870,
              February 2013.

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

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, May 2013.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

14.2.  Informative References

   [RFC2922]  Bierman, A. and K. Jones, "Physical Topology MIB",
              RFC 2922, September 2000.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026, March 2005.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

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

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

   [LDP-CRYPTO]
              Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
              Cryptographic Authentication", Work in Progress,
              June 2014.

Top      Up      ToC       Page 83 
Authors' Addresses

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO  80112
   United States
   EMail: lmartini@cisco.com


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


   Ali Sajassi
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   United States
   EMail: sajassi@cisco.com


   Matthew Bocci
   Alcatel-Lucent
   Voyager Place
   Shoppenhangers Road
   Maidenhead
   Berks, SL6 2PJ
   UK
   EMail: matthew.bocci@alcatel-lucent.com


   Satoru Matsushima
   Softbank Telecom
   1-9-1, Higashi-Shinbashi, Minato-ku
   Tokyo  105-7304
   Japan
   EMail: satoru.matsushima@g.softbank.co.jp


   Thomas Nadeau
   Brocade
   EMail: tnadeau@brocade.com