wdiff rfc7275.original rfc7275.txt

Internet Engineering Task Force Luca (IETF) L. Martini
Internet Draft Samer
Request for Comments: 7275 S. Salam
Intended status:
Category: Standards Track Ali A. Sajassi
Expires: September 27, 2014
ISSN: 2070-1721 Cisco

Matthew
M. Bocci Satoru Matsushima
Alcatel-Lucent
S. Matsushima
Softbank

Thomas Telecom
T. Nadeau
Brocade
March 27,
June 2014

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

draft-ietf-pwe3-iccp-16.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

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

This Internet-Draft will expire on September 27, 2014

Abstract

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

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7275.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

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

Table of Contents

1. Introduction ....................................................5
2. Specification of Requirements ........................ 5
2 Introduction ......................................... 5
3 ...................................5
3. ICCP Overview ........................................ 5
3.1 ...................................................5
3.1. Redundancy Model & and Topology .......................... 5
3.2 ..............................5
3.2. ICCP Interconnect Scenarios .......................... 7
3.2.1 ................................7
3.2.1. Co-located Dedicated Interconnect .................... 7
3.2.2 ...................7
3.2.2. Co-located Shared Interconnect ....................... 8
3.2.3 ......................8
3.2.3. Geo-redundant Dedicated Interconnect ................. 8
3.2.4 ................8
3.2.4. Geo-redundant Shared Interconnect .................... 9
3.3 ...................9
3.3. ICCP Requirements .................................... 10
4 .........................................10
4. ICC LDP Protocol Extension Specification ............. 12
4.1 .......................11
4.1. LDP ICCP Capability Advertisement .................... 13
4.2 .........................12
4.2. RG Membership Management ............................. 13
4.2.1 ..................................12
4.2.1. ICCP Connection State Machine ........................ 14
4.3 ......................13
4.3. Redundant Object Identification ...................... 17
4.4 ...........................17
4.4. Application Connection Management .................... 17
4.4.1 .........................17
4.4.1. Application Versioning ............................... 18
4.4.2 .............................18
4.4.2. Application Connection State Machine ................. 19
4.5 ...............19
4.5. Application Data Transfer ............................ 22
4.6 .................................22
4.6. Dedicated Redundancy Group LDP session ............... 22
5 Session ....................22
5. ICCP PE Node Failure / Isolation Detection Mechanism . 23
6 ...........22
6. ICCP Message Formats ................................. 24
6.1 ...........................................23
6.1. Encoding ICC into LDP Messages ...................... 24
6.1.1 ............................23
6.1.1. ICC Header ........................................... 24
6.1.2 .........................................24
6.1.2. ICC Parameter Encoding ............................... 26
6.1.3 .............................26
6.1.3. Redundant Object Identifier Encoding ................. 27
6.2 ...............27
6.2. RG Connect Message ................................... 28
6.2.1 ........................................27
6.2.1. ICC Sender Name TLV .................................. 29
6.3 ................................28
6.3. RG Disconnect Message ................................ 29
6.4 .....................................29
6.4. RG Notification Message .............................. 32
6.4.1 ...................................31
6.4.1. Notification Message TLVs ............................ 32
6.5 ..........................32
6.5. RG Application Data Message .......................... 36
7 ...............................35
7. Application TLVs ..................................... 36
7.1 ...............................................35
7.1. Pseudowire Redundancy (PW-RED) Application TLVs ...... 36
7.1.1 ...........35
7.1.1. PW-RED Connect TLV ................................... 36
7.1.2 .................................36
7.1.2. PW-RED Disconnect TLV ................................ 37
7.1.2.1 ..............................37
7.1.2.1. PW-RED Disconnect Cause TLV .......................... 38
7.1.3 ...............38
7.1.3. PW-RED Config TLV .................................... 39
7.1.3.1 ..................................39
7.1.3.1. Service Name TLV ..................................... 41
7.1.3.2 ..........................41
7.1.3.2. PW ID TLV ............................................ 42
7.1.3.3 .................................42
7.1.3.3. Generalized PW ID TLV ................................ 43
7.1.4 .....................43
7.1.4. PW-RED State TLV ..................................... 44
7.1.5 ...................................44
7.1.5. PW-RED Synchronization Request TLV ................... 45
7.1.6 .................45
7.1.6. PW-RED Synchronization Data TLV ...................... 47
7.2 Multi-chassis ....................46
7.2. Multi-Chassis LACP (mLACP) Application TLVs .......... 48
7.2.1 ...............48
7.2.1. mLACP Connect TLV .................................... 48
7.2.2 ..................................48
7.2.2. mLACP Disconnect TLV ................................. 49
7.2.2.1 ...............................49
7.2.2.1. mLACP Disconnect Cause TLV ........................... 50
7.2.3 ................50
7.2.3. mLACP System Config TLV .............................. 50
7.2.4 ............................51
7.2.4. mLACP Aggregator Config TLV .......................... 51
7.2.5 ........................52
7.2.5. mLACP Port Config TLV ................................ 53
7.2.6 ..............................54
7.2.6. mLACP Port Priority TLV .............................. 55
7.2.7 ............................56
7.2.7. mLACP Port State TLV ................................. 57
7.2.8 ...............................58
7.2.8. mLACP Aggregator State TLV ........................... 59
7.2.9 .........................60
7.2.9. mLACP Synchronization Request TLV .................... 61
7.2.10 ..................61
7.2.10. mLACP Synchronization Data TLV ....................... 63
8 ....................63
8. LDP Capability Negotiation ........................... 64
9 .....................................65
9. Client Applications .................................. 65
9.1 ............................................66
9.1. Pseudowire Redundancy Application Procedures ......... 65
9.1.1 ..............66
9.1.1. Initial Setup ........................................ 66
9.1.2 ......................................66
9.1.2. Pseudowire Configuration Synchronization ............. 66
9.1.3 ...........66
9.1.3. Pseudowire Status Synchronization .................... 67
9.1.3.1 ..................67
9.1.3.1. Independent Mode ..................................... 68
9.1.3.2 ..........................69
9.1.3.2. Master/Slave Mode .................................... 69
9.1.4 .........................69
9.1.4. PE Node Failure or Isolation ......................... 69
9.2 .......................70
9.2. Attachment Circuit Redundancy Application Procedures . 70
9.2.1 ......70
9.2.1. Common AC Procedures ................................. 70
9.2.1.1 ...............................70
9.2.1.1. AC Failure ........................................... 70
9.2.1.2 ................................70
9.2.1.2. Remote PE Node Failure or Isolation .................. 70
9.2.1.3 .......70
9.2.1.3. Local PE Isolation ................................... 70
9.2.1.4 ........................71
9.2.1.4. Determining Pseudowire State ......................... 71
9.2.2 Multi-chassis ..............71
9.2.2. Multi-Chassis LACP (mLACP) Application Procedures .... 71
9.2.2.1 ..72
9.2.2.1. Initial Setup ........................................ 71
9.2.2.2 .............................72
9.2.2.2. mLACP Aggregator and Port Configuration .............. 73
9.2.2.3 ...74
9.2.2.3. mLACP Aggregator and Port Status
Synchronization ..... 74
9.2.2.4 ...........................75
9.2.2.4. Failure and Recovery ................................. 76
10 ......................77
10. Security Considerations .............................. 77
11 .......................................78
11. Manageability Considerations ......................... 78
12 ..................................79
12. IANA Considerations .................................. 78
12.1 MESSAGE TYPE NAME SPACE .............................. 78
12.2 ...........................................79
12.1. Message Type Name Space ..................................79
12.2. TLV TYPE NAME SPACE .................................. 78
12.3 Type Name Space ......................................79
12.3. ICC RG Parameter Type Space .......................... 79
12.4 STATUS CODE NAME SPACE ............................... 80
13 ..............................80
12.4. Status Code Name Space ...................................81
13. Acknowledgments ...................................... 80
14 ...............................................81
14. References ....................................................81
14.1. Normative References ................................. 80
15 .....................................81
14.2. Informative References ............................... 81
16 Author's Addresses ................................... 81 ...................................82

1. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

2. Introduction

Network availability is a critical metric for service providers providers, as
it has a direct bearing on their profitability. Outages translate
not only to lost revenue but also to potential penalties mandated by
contractual agreements with customers running mission-critical
applications that require tight SLAs. Service Level Agreements (SLAs).
This is true for any carrier network, and networks employing Layer 2
Virtual Private Network (L2VPN) technology are no exception. Network high-availability A high
degree of network availability can be achieved by employing intra intra-
and inter-chassis redundancy mechanisms. The focus of this document
is on the latter. The This document defines an Inter-Chassis
Communication Protocol (ICCP) that allows synchronization of state
and configuration data between a set of two or more Provider Edge
nodes (PEs) forming a Redundancy Group (RG). The protocol supports
multi-chassis redundancy mechanisms that can be employed on either
the attachment circuits or pseudowires. pseudowires (PWs). A formal definition of
the term chassis "chassis" can be found in [RFC2922]. For the purpose of
this document, a chassis is an L2VPN PE node.

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

2. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

3. ICCP Overview

3.1. Redundancy Model & and Topology

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

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

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

Figure 1: Generic Multi-chassis Multi-Chassis Redundancy Model

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

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

3.2. ICCP Interconnect Scenarios

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

3.2.1. Co-located Dedicated Interconnect

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

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

Figure 2: ICCP Co-located PEs Dedicated Interconnect Scenario

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

3.2.2. Co-located Shared Interconnect

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

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

Figure 3: ICCP Co-located PEs Shared Interconnect Scenario

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

3.2.3. Geo-redundant Dedicated Interconnect

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

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

Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario

3.2.4. Geo-redundant Shared Interconnect

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

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

Figure 5: ICCP Geo-redundant PEs Shared Interconnect Scenario

3.3. ICCP Requirements

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

-i.

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

-ii.

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

-iii.

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

-iv.

iv. ICCP MUST provide a common mechanism to actively monitor the
health of PEs in an RG. This mechanism will be used to detect
PE node failure (or isolation from the MPLS network in the case
of shared interconnect), interconnect) and inform the client applications.
The applications require this to that the mechanism trigger failover
according to the procedures of the employed redundancy protocol employed
on the AC attachment circuit (AC) and PW. The solution SHOULD
achieve sub-second detection of loss of remote node (~ 50 -
150
(~50-150 msec) in order to give the client applications
(redundancy mechanisms) enough reaction time to achieve
sub-second service restoration time.s

-v. times.

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

-vi.

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

-vii.

vii. ICCP MUST ensure transport security between devices in an RG.
This is especially important in the scenario where the members
of an RG are located in different physical locations and
connected over a shared network (e.g. (e.g., PSN). In particular,
ICCP MUST NOT accept connections arbitrarily from any device;
otherwise, the state of client applications might be
compromised. Furthermore, even if an ICCP connection request
appears to come from an eligible device, its source address may
have been spoofed. Therefore, some means of preventing source
address spoofing MUST be in place.

-viii.

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

-ix.

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

4. ICC LDP Protocol Extension Specification

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

-i.

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

-ii. Inter Chassis

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

-iii.

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

4.1. LDP ICCP Capability Advertisement

When an RG is enabled on a particular PE, an LDP session MUST be
created to every
remote PE in that RG, RG MUST be created, if one does not already exist.
Then, the
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 LDP "ICCP capability TLV. TLV". If
an LDP peer supports the dynamic capability advertisement, this can
be done by sending a new capability message with the S bit S-bit set for
the ICCP "ICCP capability TLV TLV" when the first RG is enabled on the PE. If
the peer does not support dynamic capability advertisement, advertisements, then the ICCP TLV
"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 "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 "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
"RG Connect" messages for that RG.

If a PE that has sent a particular RG Connect "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 "RG Connect" message (or
Notification message). The RG will not become operational until the
corresponding RG Connect
Message "RG Connect" message has been received. If a PE that
has sent an RG Connect "RG Connect" message receives a Notification message
rejecting the connection, with a NAK TLV (section (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 "RG Connect" message if at least one
of the following conditions is satisfied:

-i.

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

-ii.

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 "RG Connect" message with an appropriate RG Connect.

A PE sends an RG Disconnect "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 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 state machine
(Section 4.4.2). The ICCP Connection State Machine state machine reacts only to RG Connect,
RG Disconnect
"RG Connect", "RG Disconnect", and RG Notification "RG Notification" messages that do
not contain any
Application TLVs. "Application TLVs". Actions and state transitions in
the Application Connection state machines have no effect on the ICCP
Connection State
Machine. state machine.

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

-NON EXISTENT:

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

-INITIALIZED:

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

-CAPSENT:

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

-CAPREC:

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

-CONNECTING:

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

-OPERATIONAL:

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

The state transition table and state transition diagram follow.

ICCP Connection State Transition Table

STATE EVENT NEW STATE

NON EXISTENT
--------------------------------------------------------------------
NONEXISTENT LDP session established INITIALIZED

INITIALIZED Transmit LDP ICCP Capability capability CAPSENT

Receive LDP ICCP Capability capability CAPREC
Action: Transmit LDP ICCP Capability capability

LDP session torn down NON EXISTENT NONEXISTENT

CAPSENT Receive LDP ICCP Capability capability CAPREC

LDP session torn down NON EXISTENT NONEXISTENT

CAPREC Transmit RG Connect Message message CONNECTING

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

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

LDP session torn down NON EXISTENT NONEXISTENT

CONNECTING Receive acceptable RG Connect Message message OPERATIONAL

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

LDP session torn down NON EXISTENT NONEXISTENT

OPERATIONAL Receive acceptable RG Disconnect Message message CAPREC

Transmit RG Disconnect Message message CAPREC

LDP session torn down NON EXISTENT NONEXISTENT
ICCP Connection State Transition Diagram

+------------+
| |
+------------------>|NON EXISTENT|
+------------------>|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/ |
Msg
msg | | |Tx RG Disconnect msg | Tx RG Connect msg |
| | | V |
| | | +------------+ |
| | +--------------------| | |
| | |OPERATIONAL |------------>+
| | | | |
| |Rx other ICCP msg/ +------------+ |
| | Tx NAK TLV ^ |
| | | |
| +----------+ Rx RG Connect msg | |
| | |---------------------+ |
+----->|CONNECTING| |
| |----------------------------------------->+
+----------+

4.3. Redundant Object Identification

ICCP offers its client applications a uniform mechanism for
identifying links, ports, forwarding constructs and constructs, and, more generally generally,
objects (e.g. (e.g., interfaces, pseudowires, VLANs, etc...) VLANs) that are being
protected in a redundant setup. These are referred to as Redundant
Objects (RO). (ROs). An example of an RO is a multi-chassis link-aggregation 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. That question; this allows
separate systems in an RG to use a common handle to reference the
protected entity entity, irrespective of its nature (e.g. (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 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. e.g., by means of device configuration. ICCP then sends an
Application-specific
"Application Connect TLV TLV" (carried in RG Connect 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
"Connect TLV", which, for example example, can be used to negotiate
parameters or attributes prior to bringing up the actual application connection. Application
Connection. The procedures for bringing up the application connection Application
Connection are similar to those of the ICCP connection: An application connection an
Application Connection between two nodes is up only when both nodes
have sent and received RG
Connect Messages "RG Connect" messages with the proper Application-specific
"Application Connect TLVs. TLVs". A PE MUST send a Notification Message message to
reject an application
connection Application Connection request if one of the following
conditions is encountered:

-i.

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

-ii.

ii. the application connection Application Connection count exceeds the PE's capabilities.

When a PE receives such a rejection notification, it MUST stop
attempting to bring up the application connection Application Connection until it receives a
new application connection Application Connection request from the remote PE. This is done
by responding to the incoming RG Connect "RG Connect" message (carrying an
Application-specific
"Application Connect TLV) TLV") with an appropriate RG Connect "RG Connect" message
(carrying a corresponding Application-specific "Application Connect TLV). TLV").

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

4.4.1. Application Versioning

During application connection setup time, 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 Application Connection is not brought up.
This is achieved through the following set of rules:

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

- If an application receives an Application-specific "Application Connect TLV TLV" with a
version number that is lower than its own, it MAY respond with an
RG Connect that has an Application-specific "Application Connect TLV 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, code and
supplying supply the version that is
supported. The above This allows an application to operate in either backwards compatible
backwards-compatible or incompatible mode.

- If an application receives an Application-specific "Application Connect TLV 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
Application Connection count has been exceeded.

4.4.2. Application Connection State Machine

A PE maintains an one Application Connection State Machine 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 "RG
Connect", "RG Disconnect", and RG Notification "RG Notification" messages that
contain an
Application TLV "Application TLV" specifying that particular application.

The Application Connection state machine has six states states, as follows:

-NON EXISTENT:

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

-RESET:

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

-CONNSENT:

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

-CONNREC:

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

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

-OPERATIONAL: 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

NON EXISTENT
-------------------------------------------------------------------
NONEXISTENT ICCP connection established RESET

RESET ICCP connection torn down NON EXISTENT NONEXISTENT

Transmit Application Connect TLV CONNSENT

Receive Application Connect TLV CONNREC

Receive any other Application TLV RESET
Action: Transmit NAK TLV
CONNSENT Receive NAK TLV RESET

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

Receive any other Application TLV RESET
Action: Transmit NAK TLV

ICCP connection torn down NON EXISTENT 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 NON EXISTENT 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 NON EXISTENT NONEXISTENT

OPERATIONAL Receive Application Disconnect TLV RESET

Transmit Applicaton Application Disconnect TLV RESET

ICCP connection torn down NON EXISTENT NONEXISTENT
ICCP Application Connection State Transition Diagram

+------------+
| |
+---------------->|NON EXISTENT|
+---------------->|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 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) / (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 TLV/Tx NAK | | | |
| +------+ +------------+ |
| | ^ Rx App Connect |
| +----------+ | TLV (A=1) |
| | |---------------------+ |
+--->|CONNECTING| |
| |----------------------------------------->+
+----------+

4.5. Application Data Transfer

When an application has information to transfer over ICCP ICCP, it
triggers the transmission of an Application Data "Application Data" message. ICCP
guarantees in-
order in-order and loss-less 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 message with NAK TLV. 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
"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 "NAK TLV" in response to a
transmitted Application Data "Application Data" message. Depending on the specifics
of the application, it may be favorable to have the PE, which PE that sent the
NAK,
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 "Application Data" message handle retransmissions in
response to a NAK. ICCP supports both models.

4.6. Dedicated Redundancy Group LDP session Session

For certain ICCP applications, it is required to exchange 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 multiple-processor
system, and to avoid head of line head-of-line blocking to other LDP applications, it may
be required to initiate
initiating a separate TCP/IP session between the two LDP
speakers. speakers may
be required.

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

A PE that requires a separate LDP session will advertise a separate
LDP adjacency with a non-zero label space identifier. This will
cause the remote peer to open a separate LDP session for this label
space. No labels need to be advertised in this label space, as it is
only used for one or a set of ICCP RGs. All relevant LDP and ICCP
procedures still apply as described in the relevant documents. [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,
failed, whereas in the case of a shared interconnect, interconnect this indicates
that either the remote PE node has either failed or that it has become isolated from the
MPLS network. This information is used by the client applications to
trigger failover according to the procedures of the
employed 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, nodes but rather reuses existing fault detection
mechanisms. The following mechanisms may be used by ICCP to detect
PE node failure:

- BFD 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 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 e.g. example, that the remote PE encounters could encounter a local
event that leads would lead to resetting the LDP session, while the PE node remains
would remain operational for purpose of traffic forwarding. 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, state-full stateful message delivery, as well
as capability negotiation between PEs. The LDP protocol offers all of these features,
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 already-defined LDP protocol infrastructure.

[RFC5036]

[RFC5036], Section 3.5 defines a generic LDP message structure. A
new set of LDP message types is defined to communicate the ICCP
information. LDP message types in the range 0x700 0x0700 to 0x70F 0x070F will be
used for ICCP.

Message types are have been allocated by IANA, and requested in the IANA
section below. IANA; see Section 12 below for
details.

6.1.1. ICC Header

Every ICCP message comprises of an ICC specific 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 Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U-bit

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

- Message Type

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

- Message Length

Two octet

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

- Message ID

Four octet

4-octet value used to identify this message. Used by the sending
PE to facilitate identifying RG Notification "RG Notification" messages that may
apply to this message. A PE sending an RG Notification "RG Notification" message
in response to this message SHOULD include this Message ID in the
"NAK TLV" of the RG Notification "RG Notification" message; see Section
6.4 "RG Notification Message". 6.4.

- ICC RG ID TLV

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

- Mandatory ICC Parameters

Variable length

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

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

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

6.1.2. ICC Parameter Encoding

The generic format of an ICC parameter is: 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. The Subsequent sections
following that
define TLVs specify a value for the U-bit.

- F-bit

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

- Type

Fourteen

14 bits indicating the ICC Parameter type.

- Length

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

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

6.1.3. Redundant Object Identifier Encoding

The Redundant Object Identifier (ROID) is a generic opaque handle
that uniquely identifies a Redundant Object (e.g. (e.g., link, bundle, VLAN,
etc...) which
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:

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

The ROID is carried within application specific application-specific TLVs.

6.2. RG Connect Message

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

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

A PE sends an RG Connect Message "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 "RG Connect"
messages should be transmitted is known via configuration or an auto-discovery 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 "RG
Connect" messages for each RG even if the receiving device(s) happen happens
to be the same.

The format of the RG Connect Message "RG Connect" message is as follows:

-i.

i. ICC header Header with Message type = "RG Connect Message" (0x0700)
-ii.

ii. ICC Sender Name TLV
-iii.

iii. Zero or one Application-specific connect TLV "Application Connect TLV"

The currently defined Application-specific connect TLVs are: "Application Connect TLVs" are as follows:

- PW-RED Connect TLV (section (Section 7.1.1)

- mLACP Connect TLV (section (Section 7.2.1)

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

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

6.2.1. ICC Sender Name TLV

A TLV that

The "ICC Sender Name TLV" carries the hostname of the sender sender, encoded
in UTF-8
[RFC3629]. [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

Set to 0x0001 (from the ICC parameter name space).

- Length

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

- Sender Name

An administratively-assigned administratively assigned name of the sending device 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 "RG Disconnect" message serves dual-purpose: a dual purpose: to signal that a
particular Application connection Connection is being closed within an RG, 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: 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 Type = 0x0701 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x0005 Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Code TLV |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Application-specific Application Disconnect TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameter TLVs |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U-bit

U=0

- Message Type

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

- Length

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

- Message ID

Defined in the "ICC Header" section Section 6.1.1 above.

- ICC RG ID

Defined in the "ICC Header" section 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 Type = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U,F Bits

both U U-bit and F F-bit

Both are set to 0.

- Type

set

Set to "Disconnect Code TLV" (0x0004) (0x0004).

- Length

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

- ICCP Status Code

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

- Optional Application-specific Application Disconnect TLV

Zero or one Application-specific "Application Disconnect TLVs which are
defined later TLV" (defined in the document. Sections 7.1.2
and 7.2.2). If the RG Disconnect "RG Disconnect" message has a status code of
"RG Removed", then it MUST NOT contain any
Application-specific "Application Disconnect TLVs,
TLVs", as the sending PE is signaling that it has left the RG and, thus, and
thus is disconnecting the ICCP RG connection, connection with all associated
client application
connections. Application Connections. If the message has a status code
of "Application Removed from RG", then it MUST contain exactly one Application-
specific
"Application Disconnect TLV, TLV", as the sending PE is only tearing
down the connection for the specified application. Other
applications, and the ICCP RG connection 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 "RG Notification" message to indicate one of the
following: to reject an ICCP connection, to reject an application
connection, Application
Connection, to reject an entire message message, or to reject one or more
TLV(s)
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 "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. "RG
Notification" message.

The format of the RG Notification Message is:

-i. "RG Notification" message is as follows:

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

ii. Notification Message TLVs. TLVs

The currently defined Notification message TLVs are:

-i. are as follows:

i. ICC Sender Name TLV
-ii. Negative-Acknowledgement

ii. Negative Acknowledgement (NAK) TLV

6.4.1. Notification Message TLVs

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

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

- U,F Bits

both U U-bit and F F-bit

Both are set to 0.

- Type

set

Set to "NAK TLV" (0x0002) (0x0002).

- Length

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

- ICCP Status Code

A status code that reflects the reason for the NAK TLV. "NAK TLV". Allowed
values are:
-i. 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 "Rejected Message ID ID" field MUST contain the
message ID of the rejected "RG Connect" message.

-ii.

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 "Rejected Message ID
ID" field MUST contain the message ID of the rejected "RG
Connect" message.

-iii.

iii. ICCP Application Connection Count Exceeded (0x00010003)

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

-iv.

iv. ICCP Application not in RG (0x00010004)

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

-v.

v. Incompatible ICCP Protocol Version (0x00010005)

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

-vi.

vi. ICCP Rejected Message (0x00010006)

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

-vii.

vii. ICCP Administratively Disabled (0x00010007)

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

- Rejected Message ID

If non-zero, four octets a 4-octet value that identifies the peer message to
which the NAK TLV "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" Message", then this field contains the TLV(s) 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" 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 Type = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Reference | Requested Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0003 for "Requested Protocol Version TLV" TLV".

- Length

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

- Connection Reference

This field is set

Set to the Type "Type" field of the Application specific "Application Connect TLV 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 protocol, it is set to 0x0001.

6.5. RG Application Data Message

The RG "RG Application Data Message 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 Application TLVs are
allowed in a single message, as long as all of these TLVs belong to
the same application. The format of the Application Data Message is:

-i. "Application Data" message
is as follows:

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

ii. Application-specific TLVs

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

7. Application TLVs

7.1. Pseudowire Redundancy (PW-RED) Application TLVs

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

7.1.1. PW-RED Connect TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0010 Type = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0010 for "PW-RED Connect TLV" TLV".

- Length

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

- Protocol Version

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

- A bit A-bit

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

- Reserved

Reserved for future use.

- Optional Sub-TLVs

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

7.1.2. PW-RED Disconnect TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0011 Type = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0011 for "PW-RED Disconnect TLV" TLV".

- Length

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

- Optional Sub-TLVs

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

7.1.2.1. PW-RED Disconnect Cause TLV

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0019 Type = 0x0019 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0019 for "PW-RED Disconnect Cause TLV" TLV".

- Length

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

- Disconnect Cause String

Variable length

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

7.1.3. PW-RED Config TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Priority | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID TLV or Generalized PW ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0012 for "PW-RED Config TLV" TLV".

- Length

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

- ROID

As defined in Section 6.1.3.

- PW Priority

Two octets

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

- Flags

Valid values are:

-i. are as follows:

i. Synchronized (0x01)

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

-ii.

ii. Purge Configuration (0x02)

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

-iii.

iii. Independent Mode (0x04)

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

-iv.

iv. Independent Mode with Request Switchover (0x08)

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

-v.

v. Master Mode (0x10)

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

-vi.

vi. Slave Mode (0x20)

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

- Sub-TLVs

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

-i.

i. Service Name TLV

-ii.

ii. One of the following: PW ID TLV or Generalized PW ID TLV

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

7.1.3.1. Service Name TLV

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0013 for "Service Name TLV" TLV".

- Length

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

- Service Name

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

7.1.3.2. PW ID TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0014 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0014 for "PW ID TLV" TLV".

- Length

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

- Peer ID

Four octet

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

- Group ID

Same as Group ID in [RFC4447] section [RFC4447], Section 5.2.

- PW ID

Same as PW ID in [RFC4447] section [RFC4447], Section 5.2.

7.1.3.3. Generalized PW ID TLV

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

- U U-bit and F bits

both F-bit

Both are set to 0.

- Type

set

Set to 0x0015 for "Generalized PW ID TLV".

- Length

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

- AGI, AII, SAII SAII, and TAII

defined

Defined in [RFC4447] section [RFC4447], Section 5.3.2.

7.1.4. PW-RED State TLV

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

The format of this TLV is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0016 Type = 0x0016 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0016 for PW-RED "PW-RED State TLV. TLV".

- Length

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

- ROID

As defined in Section 6.1.3.

- Local PW State

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

- Remote PW State

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

7.1.5. PW-RED Synchronization Request TLV

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

- configuration and/or state for one or more pseudowires

- configuration and/or state for all pseudowires

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

The format of the TLV is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0017 Type = 0x0017 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0017 for "PW-RED Synchronization Request TLV" TLV".

- Length

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

- Request Number

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

- C Bit C-bit

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

- S Bit S-bit

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

- Request Type

14-bits

14 bits specifying the request type, encoded as follows:

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

- Optional Sub-TLVs

A set of zero or more TLVs, as follows:

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

7.1.6. PW-RED Synchronization Data TLV

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

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

This TLV has the following format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0018 Type = 0x0018 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0018 for "PW-RED Synchronization Data TLV" TLV".

- Length

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

- Request Number

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

- Flags

2 octets, response octets. Response flags encoded as follows:

0x00 Synchronization Data Start
0x01 Synchronization Data End

7.2. Multi-chassis Multi-Chassis LACP (mLACP) Application TLVs

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

7.2.1. mLACP Connect TLV

This TLV is included in the RG Connect "RG Connect" message to signal the
establishment of an mLACP application connection. Application Connection.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0030 Type = 0x0030 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0030 for "mLACP Connect TLV" TLV".

- Length

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

- Protocol Version

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

- A Bit A-bit

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

- Reserved

Reserved for future use.

- Optional Sub-TLVs

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

7.2.2. mLACP Disconnect TLV

This TLV is used in an RG Disconnect Message "RG Disconnect" message to indicate that the
connection for the mLACP application is to be terminated.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0031 Type = 0x0031 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0031 for "mLACP Disconnect TLV" TLV".

- Length

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

- Optional Sub-TLVs

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

7.2.2.1. mLACP Disconnect Cause TLV

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x003A Type = 0x003A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x003A for "mLACP Disconnect Cause TLV" TLV".

- Length

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

- Disconnect Cause String

Variable length

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

7.2.3. mLACP System Config TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0032 Type = 0x0032 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0032 for "mLACP System Config TLV" TLV".

- Length

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

- System ID

6 octets

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

- System Priority

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

- Node ID

One octet,

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

- Most significant bit always set to 1

- The next 3 most significant bits set to Node ID

- Remaining 12 bits freely assigned by the system

7.2.4. mLACP Aggregator Config TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0036 Type = 0x0036 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Member Ports Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Agg Name Len | Aggregator Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0036 for "mLACP Aggregator Config TLV" TLV".

- Length

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

- ROID

Defined in the 'ROID Encoding' section Section 6.1.3 above.

- Aggregator ID

Two octets,

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

- MAC Address

Six

6 octets encoding the Aggregator MAC Media Access Control (MAC)
address.

- Actor Key

Two octets,

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

- Member Ports Priority

Two octets,

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

- Flags

Valid values are:

-i. are as follows:

i. Synchronized (0x01)

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

-ii.

ii. Purge Configuration (0x02)

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

-iii.

iii. Priority Set (0x04)

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

- Agg Name Len

One octet, length

1 octet. Length of the "Aggregator Name" field in octets.

- Aggregator Name

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

7.2.5. mLACP Port Config TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0033 Type = 0x0033 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | MAC Address |
+-------------------------------+ +
| |
+---------------------------------------------------------------+
| Actor Key | Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Port Name Len | Port Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0033 for "mLACP Port Config TLV" TLV".

- Length

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

- Port Number

Two octets,

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

- MAC Address

Six

6 octets encoding the port MAC address.

- Actor Key

Two octets,

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

- Port Priority

Two octets,

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

- Port Speed

Four octets

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

- Flags

Valid values are:

-i. are as follows:

i. Synchronized (0x01)

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

-ii.

ii. Purge Configuration (0x02)

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

-iii.

iii. Priority Set (0x04)

Indicates that the "Port Priority" field is valid.

- Port Name Len

One octet, length

1 octet. Length of the "Port Name" field in octets.

- Port Name

This field corresponds

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

7.2.6. mLACP Port Priority TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0034 Type = 0x0034 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | Last Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0034 for "mLACP Port Priority TLV" TLV".

- Length

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

- OpCode

Two

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

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

- Port Number

2 octets

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

- Aggregator ID

Two octets,

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

- Last Port Priority

Two octets,

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

- Current Port Priority

Two octets,

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

7.2.7. mLACP Port State TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0035 Type = 0x0035 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Port Number | Partner Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Partner State | Actor State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Port Number | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Selected | Port State | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0035 for "mLACP Port State TLV" TLV".

- Length

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

- Partner System ID

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

- Partner System Priority

2 octets

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

- Partner Port Number

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

- Partner Port Priority

2 octets

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

- Partner Key

2 octets

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

- Partner State

1 octet

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

- Actor State

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

- Actor Port Number

2 octets

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

- Actor Key

2 octet

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

- Selected

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

0x00 SELECTED
0x01 UNSELECTED
0x02 STANDBY
- Port State

1 octet encoding the operational state of the port as follows:

0x00 Up
0x01 Down
0x02 Administrative Administratively Down
0x03 Test (e.g. (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)

- Aggregator ID

Two octets,

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

7.2.8. mLACP Aggregator State TLV

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0037 Type = 0x0037 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Agg State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0037 for "mLACP Aggregator State TLV" TLV".

- Length

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

- Partner System ID

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

- Partner System Priority

2 octets

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

- Partner Key

2 octets

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

- Aggregator ID

Two octets,

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

- Actor Key

2 octet

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

- Agg State

1 octet encoding the operational state of the Aggregator as
follows:

0x00 Up
0x01 Down
0x02 Administrative Administratively Down
0x03 Test (e.g. (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)

7.2.9. mLACP Synchronization Request TLV

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

- system configuration and/or state

- configuration and/or state for a specific port

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

- configuration and/or state for a specific aggregator Aggregator

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

- configuration and/or state for all mLACP aggregators Aggregators

The format of the TLV is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0038 Type = 0x0038 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number / Aggregator ID | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0038 for "mLACP Synchronization Request TLV" TLV".

- Length

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

- Request Number

- C Bit C-bit

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

- S Bit S-bit

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

- Request Type

14-bits

14 bits specifying the request type, encoded as follows:

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

- Port Number / Aggregator ID

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

- Actor Key

Two octets,

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

7.2.10. mLACP Synchronization Data TLV

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

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

This TLV has the following format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x0039 Type = 0x0039 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- U U-bit and F Bits F-bit

Both are set to 0.

- Type

set

Set to 0x0039 for "mLACP Synchronization Data TLV" TLV".

- Length

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

- Request Number

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

- Flags

2 octets, response flags octets. Response flags, encoded as follows:

0x00 Synchronization Data Start
0x01 Synchronization Data End

8. LDP Capability Negotiation

As requited required in [RFC5561] [RFC5561], the following TLV is defined to indicate
the ICCP capability:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| TLV Code Point=0x700 Point = 0x0700 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved | VER/Maj Ver/Maj | Ver/Min |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:

- U-bit

SHOULD be 1 (ignore if not understood).

- F-bit

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

- TLV Code Point

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

- S-bit The

State Bit indicates bit. Indicates whether the sender is advertising or
withdrawing the ICCP capability. The State bit is used as follows:

1 - The TLV is advertising the capability specified by the TLV Code
Point.

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

- Ver/Maj

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

- Ver/Min

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

ICCP capability is advertised to a 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. application.

It should be noted that the PW-RED application SHOULD NOT be enabled
together with an AC Redundancy 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 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 A-bit to 0. If a PE, PE that has sent the TLV with
the A bit A-bit set to 0, 0 receives a "PW-RED Connect TLV" from a peer, it
MUST repeat its advertisement with the A bit A-bit set to 1. The PW-RED
application connection
Application Connection is considered to be operational when both PEs
have sent and received "PW-RED Connect TLVs" with the A bit A-bit set to 1.
Once the application connection 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 differing different Protocol Version, it must follow the
procedures outlined in the "Application Versioning" section Section 4.4.1 above.

When the PW-RED application is disabled on the device, 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
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
"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 up-to-date information for the affected pseudowires.

As part of the configuration synchronization, a PE advertises the
ROID associated with the pseudowire. This is used to correlate the
pseudowires that are protecting each other on different PEs. As well,
a A PE
also advertises the configured PW redundancy mode. This can be one
of the following four options: Master Mode, Slave Mode, Independent Mode
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" Notification" message
to reject the "PW-RED Config TLV". The PE MUST disable the
associated local pseudowire until a satisfactory "PW-RED Config TLV"
is received from the peer. This guarantees that device mis-configuration
misconfiguration does not lead to network wide network-wide problems (e.g. (e.g., by
creating forwarding loops). The PE SHOULD also raise an alarm to
alert the operator. If a PE receives a NAK TLV "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 active role in a redundant setup. A PE also adverties 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,

PEs that are member members of an RG, RG synchronize pseudowire status for the
purpose of identifying, on a per ROID 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
PW-RED state. This is useful useful, for instance 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 "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
"Synchronization Response TLV TLV" with the "Synchronization Data Start"
flag precedes the various other PW-RED TLVs "PW-RED TLVs" encoding the requested
data. These, in turn, MUST precede the Synchronization "Synchronization Data TLV TLV"
with the "Synchronization Data End" flag. It is worth noting that
the response may span across multiple RG "RG Application Data Data" messages;
however, the above TLV ordering MUST be retained across messages, and
only a single pair of Synchronization "Synchronization Data TLVs TLVs" must be used to
delimit the response across all Application Data Messages. "Application Data" messages.

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

While a PE has a pending synchronization request for a pseudowire or
a service, it SHOULD silently ignore all TLVs for said pseudowire or
service that are received prior to the synchronization response and
which
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.
(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, 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 the all of the PEs in an RG have exchanged their
"PW-RED State TLVs", the PE with the best PW Priority (i.e. (i.e., least
numeric value) advertises Active preferential forwarding active Preferential Forwarding status in
LDP on all of its associated pseudowires. Whereas, pseudowires, whereas all other PEs in
the RG advertise Standby preferential forwarding 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 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 active Preferential Forwarding status
on both PW endpoints, as described in [RFC6870].

9.1.3.2. Master/Slave Mode

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. (i.e., least numeric
value) advertises Active preferential forwarding active Preferential Forwarding status in LDP on
only a single pseudowire, following the procedures in sections Sections 5.2
and 6.2 of [RFC6870]. Whereas, [RFC6870], whereas all of the other pseudowires on other
PEs in the RG are advertised with Standby preferential forwarding standby Preferential Forwarding
status in LDP.

9.1.4. PE Node Failure or Isolation

When a PE node detects that a remote PE, PE that is a member of the same
RG,
RG is no longer reachable (using the mechanisms of described in
Section 5), the local PE examines determines if it has redundant PWs for the
affected services. If the local PE has the highest priority (after
the failed PE) PE), then it becomes the active node for the services in question,
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 redundancy
applications, independent of the type of the AC (ATM, FR FR, or
Ethernet).

9.2.1.1. AC Failure

When the AC Redundancy redundancy mechanism on the Active active PE detects a failure
of the AC, it should send an ICCP Application Data "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, PE that is a member of the same
RG,
RG is no longer reachable (using the mechanisms of described in
Section 5), the local PE examines determines if it has redundant ACs for the
affected services. If the local PE has the highest priority (after
the failed PE) PE), then it becomes the active node for the services in question,
question and subsequently activates its associated ACs.

9.2.1.3. Local PE Isolation

When a PE node detects that is it has been isolated from the core
network (i.e. (i.e., all core facing core-facing interfaces/links are not operational),
then it should ensure that its AC Redundancy redundancy mechanism will change
the status of any active ACs to Standby. standby. The AC Redundancy redundancy
application SHOULD then send ICCP Application Data "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) 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 redundancy application over
ICCP, then the Independent Mode of PW Redundancy, redundancy, as defined in
[RFC6870], MUST be used. On a given PE, the Preferential Forwarding
status of the PW (Active (active or Standby) 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,
active, then the PW status should be Active. active. If the AC is
Standby, standby,
then the PW status should be Standby. standby.

- VPLS

For VPLS, there could be multiple ACs per service instance (i.e.
VFI). (i.e.,
Virtual Switch Instance (VSI) [RFC4026]). If AT LEAST ONE AC is Active,
active, then the PW status should be
Active. active. If ALL ACs are Standby,
standby, then the PW status should be
Standby. standby.

In this case, the PW-RED application is not used to synchronize PW
status between PEs. Rather, the AC Redundancy redundancy application should
synchronize AC status between PE, PEs, in order to establish which AC
(and subsequently which PE) is Active active or Standby standby for a given service.
When that is determined, each PE will then derive its local PWs 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 Multi-Chassis LACP (mLACP) Application Procedures

This section defines the procedures that are specific to the multi-
chassis
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 A-bit to 1 in the said TLV if it has received a
corresponding "mLACP Connect TLV" from its peer PE; otherwise, the
sending PE MUST set the A bit A-bit to 0. If a PE receives an "mLACP
Connect TLV" from its peer after sending the said TLV with the A bit A-bit set
to 0, it MUST resend the TLV with the A bit A-bit set to 1. A system
considers the mLACP application connection Application Connection to be operational when it
has sent and received "mLACP Connect TLVs" with the A bit A-bit set to 1.
When the mLACP application connection Application Connection between a pair of PEs is
operational, the two devices can start exchanging "RG Application
Data" messages for the mLACP application. This involves having each
PE advertise its mLACP configuration and operational state in an
unsolicited manner. A PE SHOULD subscribe to use the following order sequence when
advertising its mLACP state upon initial application connection 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 differing different Protocol Version, it MUST follow the
procedures outlined in the "Application Versioning" section Section 4.4.1 above.

After the mLACP application connection Application Connection has been established, every PE
MUST communicate its system level 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" 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 "NAK TLV" for an "mLACP System Config TLV" that it
has advertised, the PE MUST suspend the mLACP application and SHOULD
raise an alarm to alert the network operator of potential device
mis-configuration.
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,
Connection, then the PE MUST respond to the new peer with an "RG
Notification Message"
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, Aggregators
and MUST replay the initialization sequence by sending an unsolicited
synchronization of: of the system configuration, Aggregator
configuration, port configuration, Aggregator state state, and port state.

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

When the mLACP application is disabled on the device, 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 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 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 "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 such that
TLV. Furthermore, the system in this case MUST NOT advertise
individual Port Priority values in the associated "mLACP Port Config
TLVs" (i.e. (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", 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 of before via an appropriate Port "Port Config TLV" or Aggregator
"Aggregator Config TLV, TLV", then the PE MUST request synchronization of
the configuration and state of all mLACP ports as well as all mLACP
Aggregators from its respective peer. If during During a synchronization
(solicited or unsolicited), if a PE receives a State TLV "State TLV" for a port
or Aggregator that it has not learned of before, then the PE MUST send a NAK TLV
"NAK TLV" for the offending TLV. The PE MUST NOT request re-synchronization
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,
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 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,
port -- whether on the Partner (i.e. (i.e., multi-homed device) side or the
Actor
(i.e. (i.e., PE) side, side -- is changed 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 Port State
TLV to its peers.

If a PE receives an Aggregator or port state Port State TLV where the 'Actor
Key' Actor Key
doesn't match what was previously received in a corresponding
Aggregator
"Aggregator Config TLV" or port config TLV, "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
Config and
state State TLVs as part of a synchronization (solicited or
unsolicited), then the PE MUST send a NAK TLV "NAK TLV" for the state TLV. "State TLV".
Furthermore, if a PE receives a port state TLV "Port State TLV" with the 'Aggregator ID' "Aggregator
ID" set to a value that doesn't map to some Aggregator that the PE
had learned of via a previous Aggregator config TLV, "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 "NAK TLV" for the offending port state TLV.
"Port State TLV".

A PE MAY request that its peer retransmit previously advertised
state. This is useful useful, for example 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 "RG Application Data Data"
message(s) such that the Synchronization "Synchronization Response TLV TLV" with the
"Synchronization Data Start" flag precedes the various other mLACP
TLVs encoding the requested data. These, in turn, MUST precede the
Synchronization
"Synchronization Data TLV TLV" with the "Synchronization Data End" flag.
Note that the response may span across multiple RG "RG Application Data
messages, Data"
messages -- for example example, when MTU limits are exceeded; however, the
above ordering MUST be retained across messages, and only a single
pair of Synchronization "Synchronization Data TLVs TLVs" MUST be used to delimit the
response across all Application Data Messages. "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' "Request Number" of 0.

While a PE has a pending synchronization request for a system,
Aggregator
Aggregator, or port, it SHOULD silently ignore all TLVs for said
system, Aggregator Aggregator, or port that are received prior to the
synchronization response and which that carry the same type of information
being requested. This saves the system from the burden of updating
state that will utlimately ultimately be overwritten by the synchronization
response. Note that TLVs pertaining to other systems, Aggregators 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 port,
or
Key key that doesn't exist or is not known to the PE, then it MUST
trigger an unsolicited synchronization of all system, Aggregator Aggregator, and
port information (i.e. (i.e., replay the initialization sequence).

If a PE learns, as part of a synchronization operation from its peer,
that the latter is advertising a Node ID value which that is different from
the value previously advertised, then the PE MUST purge all
port/aggregator
Port/Aggregator data previously learnt 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 fail over to
a peer PE which that hosts the same RO. The default fail-over failover procedure is
to have the failed PE bring down the link(s) link or links towards the
multi-homed CE (e.g. (e.g., by bringing down the line-protocol). line protocol). This will
cause the CE to fail-over fail over to the other member link(s) link or links of the
bundle that are connected to the other PE(s) in the RG. Other
procedures for triggering fail-over failover are possible, and 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. (i.e., numerically larger) for the Aggregator in question.

If a system is operating in a mode where different ports of a bundle
are configured with different Port Priorities, then the system MUST
NOT advertise or request change changes of Port Priority values for
aggregated ports collectively (i.e. (i.e., by using a 'Port Number' "Port Number" of 0 in
the "mLACP Port Priority TLV"). This is to avoid ambiguity in the
interpretation of the 'Last "Last Port Priority' 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 of before via an appropriate Port "Port
Config TLV" or
Aggregator "Aggregator Config TLV, 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 well-managed and highly monitored
networks. It ought not be deployed on or over the public Internet.
The
ICCP protocol is not intended to be applicable when the
redundancy group Redundancy Group spans PE
PEs in different administrative domains.

The security considerations described in [RFC5036] and [RFC4447] that
apply to the base LDP specification, specification and to the PW LDP control
protocol extensions apply to the capability mechanism described in
this document. In particular, ICCP implementations MUST provide a
mechanism to select to which LDP peers the ICCP capability will be
advertised, and from which LDP peers the ICCP messages will be
accepted. Therefore, an incoming ICCP connection request MUST NOT be
accepted unless its source IP address is known to be the source of an
"eligible" ICCP peer. The set of eligible peers could be pre-
configured (either as
preconfigured (as a list of either IP addresses, addresses or as a list of address/mask
combinations), or it could be discovered dynamically via some secure
discovery protocol. The TCP Authentication Option (TCP-
AO), (TCP-AO), as
defined in [RFC5925], SHOULD be used. This provides integrity and
authentication for the ICCP messages and eliminates the
possiblity 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 Section 2.9 of
[RFC5036] [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]
[LDP-CRYPTO] aimed at addressing LDP's vulnerabilities are applicable
as well.

Furthermore, activitiy activity on the attachment ciruits circuits may cause security
threats or be exploited to create denial of service attackes. denial-of-service attacks. For
example, a malicious CE implementation may trigger continuously
variying
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 such these types of attacks.

11. Manageability Considerations

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

12. IANA Considerations

12.1. MESSAGE TYPE NAME SPACE Message Type Name Space

This document uses several new LDP message types, types. IANA already maintains a the
"Message Type Name Space" registry of name "MESSAGE TYPE NAME SPACE" as defined by [RFC5036]. The
following values are suggested for assignment: have been assigned:

Message type 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 Type Name Space

This document uses a new LDP TLV type, type. IANA already maintains a
registry of name the "TLV TYPE NAME SPACE" Type
Name Space" registry as defined by [RFC5036]. The following value is suggested for assignment:
has been assigned:

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

12.3. ICC RG Parameter Type Space

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

This document use uses several new Status codes, codes. IANA already maintains a the
"Status Code Name Space" registry of name "STATUS CODE NAME SPACE" as defined by [RFC5036]. The
following values is suggested for assignment: The 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 Ketley, and Mark Christopher Sains.

The authors also thank Daniel Cohn, Lizhong Jin Jin, and Ran Chen for the
their valuable input, discussions 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] L. Andersson et al, 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", RFC5561, RFC 5561, July 2009.

[RFC4447] "Transport of Layer 2 Frames Over MPLS",

[RFC4447] Martini, L.,
et al., rfc4447 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 networks--Link Aggregation", IEEE
Computer Society, November 2008.

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

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

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

[RFC6952] M. Jethanandani et al., 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", rfc6952, RFC 6952, May 2013.

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

15.

14.2. Informative References

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

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

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

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

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

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

16. Author's Progress,
June 2014.

Authors' Addresses

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

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

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

Matthew Bocci
Alcatel-Lucent
Grove House, Waltham
Voyager Place
Shoppenhangers Road Rd
White Waltham,
Maidenhead
Berks, UK. SL6 3TN
e-mail: matthew.bocci@alcatel-lucent.co.uk 2PJ
UK
EMail: matthew.bocci@alcatel-lucent.com

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

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

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