RFC 7275
Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy
Pages: 83
Proposed Standard
Proposed Standard
Part 4 of 4 – Pages 65 to 83
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.
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"
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.
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].
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
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 CE9.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.
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.
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.
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".
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
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".
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.
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.
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.
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 use12.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
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
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 RG13. 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.
[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.
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