doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc7727.txt b/doc/rfc/rfc7727.txt
new file mode 100644
index 0000000..c389a90
--- /dev/null
+++ b/doc/rfc/rfc7727.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          M. Zhang
+Request for Comments: 7727                                        H. Wen
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                                    J. Hu
+                                                           China Telecom
+                                                            January 2016
+
+
+                Spanning Tree Protocol (STP) Application
+           of the Inter-Chassis Communication Protocol (ICCP)
+
+Abstract
+
+   The Inter-Chassis Communication Protocol (ICCP) supports an inter-
+   chassis redundancy mechanism that is used to support high network
+   availability.
+
+   In this document, Provider Edge (PE) devices in a Redundancy Group
+   (RG) running ICCP are used to offer multihomed connectivity to
+   Spanning Tree Protocol (STP) networks to improve availability of the
+   STP networks.  The ICCP TLVs and usage for the ICCP STP application
+   are defined.
+
+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/rfc7727.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 1]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 2]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Conventions Used in This Document ..........................4
+      1.2. Terminology ................................................4
+   2. Use Case ........................................................5
+   3. Spanning Tree Protocol Application TLVs .........................6
+      3.1. STP Connect TLV ............................................6
+      3.2. STP Disconnect TLV .........................................7
+           3.2.1. STP Disconnect Cause Sub-TLV ........................8
+      3.3. STP Configuration TLVs .....................................8
+           3.3.1. STP System Config ...................................9
+           3.3.2. STP Region Name ....................................10
+           3.3.3. STP Revision Level .................................10
+           3.3.4. STP Instance Priority ..............................11
+           3.3.5. STP Configuration Digest ...........................12
+      3.4. STP State TLVs ............................................12
+           3.4.1. STP Topology Changed Instances .....................12
+           3.4.2. STP CIST Root Time Parameters ......................14
+           3.4.3. STP MSTI Root Time Parameter .......................15
+      3.5. STP Synchronization Request TLV ...........................16
+      3.6. STP Synchronization Data TLV ..............................17
+   4. Operations .....................................................18
+      4.1. Common AC Procedures ......................................18
+           4.1.1. Remote PE Node Failure or Isolation ................19
+           4.1.2. Local PE Isolation .................................19
+      4.2. ICCP STP Application Procedures ...........................19
+           4.2.1. Initial Setup ......................................19
+           4.2.2. Configuration Synchronization ......................20
+           4.2.3. State Synchronization ..............................21
+           4.2.4. Failure and Recovery ...............................22
+   5. Security Considerations ........................................22
+   6. IANA Considerations ............................................23
+   7. References .....................................................23
+      7.1. Normative References ......................................23
+      7.2. Informative References ....................................24
+   Acknowledgements ................................................. 24
+   Authors' Addresses ............................................... 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 3]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+1.  Introduction
+
+   Inter-Chassis Communication Protocol (ICCP [RFC7275]) specifies a
+   multi-chassis redundancy mechanism that enables Provider Edge (PE)
+   devices located in a multi-chassis arrangement to act as a single
+   Redundancy Group (RG).
+
+   With the Spanning Tree Protocol (STP), a spanning tree will be formed
+   over connected bridges by blocking some links between these bridges
+   so that forwarding loops are avoided.  This document introduces
+   support of STP as a new application of ICCP.  When a bridged STP
+   network is connected to an RG, this STP application of ICCP enables
+   the RG members to act as a single root bridge participating in the
+   operations of STP.
+
+   STP-relevant information needs to be exchanged and synchronized among
+   the RG members.  New ICCP TLVs for the ICCP STP application are
+   specified for this purpose.
+
+   From the point of view of the customer, the Service Provider is
+   providing a Virtual Private LAN Service (VPLS) [RFC4762].
+
+1.1.  Conventions Used in This Document
+
+   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].
+
+1.2.  Terminology
+
+   ICCP: Inter-Chassis Communication Protocol
+   VPLS: Virtual Private LAN Service
+   STP:  Spanning Tree Protocol
+   MSTP: Multiple Spanning Tree Protocol
+   MST:  Multiple Spanning Trees
+   CIST: Common and Internal Spanning Tree ([802.1q], Section 3.27)
+   MSTI: Multiple Spanning Tree Instance ([802.1q], Section 3.138)
+   BPDU: Bridge Protocol Data Unit
+
+   In this document, unless otherwise explicitly noted, the term "STP"
+   also covers MSTP.
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 4]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+2.  Use Case
+
+   Customers widely use Ethernet as an access technology [RFC4762].
+   It's common that one customer's Local Area Network (LAN) has multiple
+   bridges connected to a carrier's network at different locations for
+   reliability purposes.  Requirements for this use case are listed as
+   follows.
+
+   o  Customers desire to balance the load among their available
+      connections to the carrier's network; therefore, all the
+      connections need to be active.
+
+   o  When one connection to the carrier network fails, customers
+      require a connection in another location to continue to work after
+      the reconvergence of the STP rather than compromising the whole
+      STP network.  The failure of the connection may be due to the
+      failure of the PE, the attachment circuit (AC), or even the
+      Customer Edge (CE) device itself.
+
+   In order to meet these requirements, the 'ICCP-STP' model is
+   proposed.  It introduces STP as a new application of ICCP.
+
+             +--------------+       +=============+
+             |              |       |             |
+             |              |       |             |
+             |       +---+  |       |  +-----+|<--|--Pseudowire-->|
+             |   +---+CE1+<6>-------<5>+ PE1 ||   |               |
+             |  <1>  +---+  |       |  +-----+|<--|--Pseudowire-->|
+             | +-+-+        |       |     ||      |
+             | |CE3|        |       |     ||ICCP  |--> Towards the Core
+             | +-+-+        |       |     ||      |
+             |  <2>  +---+  |       |  +-----+|<--|--Pseudowire-->|
+             |   +---+CE2+<3>-------<4>+ PE2 ||   |               |
+             |       +---+  |       |  +-----+|<--|--Pseudowire-->|
+             |              |       |             |
+             | Multihomed   |       |  Redundancy |
+             | STP Network  |       |    Group    |
+             +--------------+       +=============+
+
+        Figure 1: A STP network is multihomed to an RG running ICCP
+
+   Figure 1 shows an example topology of this model.  With ICCP, the
+   whole RG will be virtualized to be a single bridge.  Each RG member
+   has its BridgeIdentifier (the MAC address).  The numerically lowest
+   one is used as the BridgeIdentifier of the 'virtualized root bridge'.
+   The RG acts as if the ports connected to the STP network (ports <4>
+   and <5>) are for the same root bridge.  All these ports send the
+   configuration BPDU with the highest root priority to trigger the
+
+
+
+Zhang, et al.                Standards Track                    [Page 5]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+   construction of the spanning tree.  The link between the peering PEs
+   is not visible to the bridge domains of the STP network.  In this
+   way, the STP will always break a possible loop within the multihomed
+   STP network by breaking the whole network into separate islands so
+   that each is attached to one PE.  That forces all PEs in the RG to be
+   active.  This is different from a generic VPLS [RFC4762] where the
+   root bridge resides in the customer network and the multihomed PEs
+   act in the active-standby mode.  Note that the specification of VPLS
+   remains unchanged other than for this operation.  For instance, a
+   full-mesh of pseudowires (PWs) is established between PEs, and the
+   "split horizon" rule is still used to perform the loop-breaking
+   through the core.
+
+3.  Spanning Tree Protocol Application TLVs
+
+   This section specifies the ICCP TLVs for the ICCP STP application.
+   The Unknown TLV bit (U-bit) and the Forward unknown TLV bit (F-bit)
+   of the following TLVs MUST be sent as cleared and processed on
+   receipt as specified in [RFC7275].
+
+3.1.  STP Connect TLV
+
+   This TLV is included in the RG Connect Message to signal the
+   initiation of an ICCP STP 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=0x2000               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Protocol Version         |A|         Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Optional Sub-TLVs                        |
+   ~                                                               ~
+   |                                                               |
+   +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             ...                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2000 for "STP Connect TLV"
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 6]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.
+
+      - Protocol Version
+
+        The version of ICCP STP application protocol.  This document
+        defines version 0x0001.
+
+      - A bit
+
+        Acknowledgement Bit.  Set to 1 if the sender has received a STP
+        Connect TLV from the recipient.  Otherwise, set to 0.
+
+      - Reserved
+
+        Reserved for future use.  These bits MUST be sent as 0 and
+        ignored on receipt.
+
+      - Optional Sub-TLVs
+
+        There are no optional Sub-TLVs defined for this version of the
+        protocol.
+
+3.2.  STP Disconnect TLV
+
+   This TLV is used in the RG Disconnect Message to indicate that the
+   connection for the ICCP STP 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=0x2001               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Optional Sub-TLVs                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2001 for "STP Disconnect TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.
+
+
+
+Zhang, et al.                Standards Track                    [Page 7]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - Optional Sub-TLVs
+
+        The only optional Sub-TLV defined for this version of the
+        protocol is the "STP Disconnect Cause" sub-TLV, defined below:
+
+3.2.1.  STP Disconnect Cause Sub-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=0x200C              |    Length                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Disconnect Cause String                  |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x200C for "STP Disconnect Cause TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.
+
+      - Disconnect Cause String
+
+        Variable-length string specifying the reason for the disconnect,
+        encoded in UTF-8 [RFC3629] format.  Used for operational
+        purposes.
+
+3.3.  STP Configuration TLVs
+
+   The STP Configuration TLVs are sent in the RG Application Data
+   Message.  When an STP Config TLV is received by a peer RG member, the
+   member MUST synchronize with the configuration information contained
+   in the TLV.  TLVs specified in Sections 3.3.1 to 3.3.5 define
+   specific configuration information.
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 8]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+3.3.1.  STP System Config
+
+   This TLV announces the local node's STP 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=0x2002               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              ROID                             |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         MAC Address                           |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2002 for "STP System Config TLV"
+
+      - Length
+
+        Length of the ROID plus the MAC address in octets.  Always set
+        to 14.
+
+      - ROID
+
+        Redundant Object Identifier; format defined in Section 6.1.3 of
+        [RFC7275].
+
+      - MAC Address
+
+        The MAC address of the sender.  This MAC address is set to the
+        BridgeIdentifier of the sender, as defined in [802.1q], Section
+        13.26.2.  The numerically lowest 48-bit unsigned value of
+        BridgeIdentifier is used as the MAC address of the Virtual Root
+        Bridge mentioned in Section 2.
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                    [Page 9]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+3.3.2.  STP Region Name
+
+   This TLV carries the value of Region Name.
+
+    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=0x2003               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Region Name                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2003 for "STP Region Name TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.
+
+      - Region Name
+
+        The Name of the MST Region as specified in [802.1q], Section
+        3.142.
+
+3.3.3.  STP Revision Level
+
+   This TLV carries the value of Revision Level.
+
+    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=0x2004               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Revision Level          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2004 for "STP Revision Level TLV".
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 10]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.  Always set to 2.
+
+      - Revision Level
+
+        The Revision Level as specified in [802.1q], Section 13.8, item
+        c.
+
+3.3.4.  STP Instance Priority
+
+   This TLV carries the value of Instance Priority 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=0x2005               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Pri  |      InstanceID       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2005 for "STP Instance Priority TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.
+
+      - Pri
+
+        The Instance Priority.  It is interpreted as unsigned integer
+        with higher value indicating a higher priority.
+
+      - InstanceID
+
+        The 12-bit Instance Identifier of the CIST or MSTI.  This
+        parameter takes a value in the range 1 through 4094 for MSTI (as
+        defined in [802.1q], Section 12.8.1.2.2) and takes value of 0
+        for CIST.
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 11]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+3.3.5.  STP Configuration Digest
+
+   This TLV carries the value of STP VLAN Instance Mapping.
+
+    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=0x2006             |    Length                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Configuration Digest                       |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2006 for "STP Configuration Digest TLV"
+
+      - Length
+
+        Length of the STP Configuration Digest in octets.  Always set to
+        16.
+
+      - Configuration Digest
+
+        As specified in [802.1q], Section 13.8, item d.
+
+3.4.  STP State TLVs
+
+   The STP State TLVs are sent in the RG Application Data Message.  They
+   are used by a PE device to report its STP status to other members in
+   the RG.  Such TLVs are specified in the following subsections.
+
+3.4.1.  STP Topology Changed Instances
+
+   This TLV is used to report the Topology Changed Instances to other
+   members of the RG.  The sender monitors Topology Change Notification
+   (TCN) messages and generates this list.  The receiving RG member MUST
+   initiate the Topology Change event, including sending BPDU with the
+   Topology Change flag set to 1 out of the designated port(s) of the
+   Topology Changed bridge domains of the STP network, and flushing out
+   MAC addresses relevant to the instances listed in this TLV.
+
+   If the PE device supports MAC Address Withdrawal (see Section 6.2 of
+   [RFC4762]), it SHOULD send a Label Distribution Protocol (LDP)
+   Address Withdraw Message with the list of MAC addresses towards the
+   core over the corresponding LDP sessions.  It is not necessary to
+
+
+
+Zhang, et al.                Standards Track                   [Page 12]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+   send such a message to PEs of the same RG since the flushing of their
+   MAC address tables should have been performed upon receipt of the STP
+   Topology Changed Instances 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=0x2007               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       InstanceID List                         |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2007 for "STP Topology Changed Instances TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.
+
+      - InstanceID List
+
+        The list of the InstanceIDs of the CIST or MSTIs whose
+        topologies have changed as indicated by the TCN messages as
+        specified in [802.1q], Section 13.14.  The list is formatted by
+        padding each InstanceID value to the 16-bit boundary as follows,
+        where the bits in the "R" fields MUST be sent as 0 and ignored
+        on receipt.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |R|R|R|R| InstanceID#1          |R|R|R|R| InstanceID#2          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                             ... ...                           ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 13]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+3.4.2.  STP CIST Root Time Parameters
+
+   This TLV is used to report the Value of CIST Root Time Parameters
+   ([802.1q], Section 13.26.7) to other members of the RG.  All time
+   parameter values are in seconds with a granularity of 1.  For ranges
+   and default values of these parameter values, refer to [802.1d1998],
+   Section 8.10.2, Table 8-3; [802.1d2004] Section 17.14, Table 17-1;
+   and [802.1q], Section 13.26.7.
+
+    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=0x2008               |    Length                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    MaxAge                     |   MessageAge                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    FwdDelay                   |   HelloTime                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | RemainingHops |
+   +-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2008 for "STP CIST Root Time TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.  Always set to 9.
+
+      - MaxAge
+
+        The Max Age of the CIST.  It is the maximum age of the
+        information transmitted by the bridge when it is the Root Bridge
+        ([802.1d2004], Section 17.13.8).
+
+      - MessageAge
+
+        The Message Age of the CIST (see [802.1q], Section 13.26.7).
+
+      - FwdDelay
+
+        The Forward Delay of the CIST.  It is the delay used by STP
+        Bridges to transition Root and Designated Ports to Forwarding
+        ([802.1d2004], Section 17.13.5).
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 14]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - HelloTime
+
+        The Hello Time of the CIST.  It is the interval between periodic
+        transmissions of Configuration Messages by Designated Ports
+        ([802.1d2004], Section 17.13.6).
+
+      - RemainingHops
+
+        The remainingHops of the CIST ([802.1q], Section 13.26.7).
+
+3.4.3.  STP MSTI Root Time Parameter
+
+   This TLV is used to report the parameter value of MSTI Root Time to
+   other members of the RG.  As defined in [802.1q], Section 13.26.7, it
+   is the value of remainingHops for the given MSTI.
+
+    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=0x2009              |    Length                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Pri  |  InstanceID           | RemainingHops |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x2009 for "STP MSTI Root Time TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.  Always set to 3.
+
+      - Pri
+
+        The Instance Priority.  It is interpreted as an unsigned integer
+        with higher value indicating a higher priority.
+
+      - InstanceID
+
+        The 12-bit Instance Identifier of the Multiple Spanning Tree
+        Instance (MSTID).  As defined in [802.1q], Section 12.8.1.2.2,
+        this parameter takes a value in the range 1 through 4094.
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 15]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - RemainingHops
+
+        The remainingHops of the MSTI.  It is encoded in the same way as
+        in [802.1q], Section 14.4.1, item f.
+
+3.5.  STP Synchronization Request TLV
+
+   The STP Synchronization Request TLV is used in the RG Application
+   Data Message.  This TLV is used by a device to request that its peer
+   retransmit configuration or operational state.  The following
+   information can be requested:
+
+      - configuration and/or state of the STP system,
+      - configuration and/or state for a given list of instances.
+
+   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=0x200A              |    Length                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      Request Number           |C|S|   Request Type            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       InstanceID List                         |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        Set to 0x200A for "STP Synchronization Request TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.  Always set to 4.
+
+      - Request Number
+
+        2 octets.  Unsigned integer uniquely identifying the request.
+        Used to match the request with a corresponding response.  The
+        value of 0 is reserved for unsolicited synchronization, and it
+        MUST NOT be used in the STP Synchronization Request TLV.  As
+        indicated in [RFC7275], given the use of TCP, there are no
+        issues associated with the wrap-around of the Request Number.
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 16]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - C-bit
+
+        Set to 1 if the request is for configuration data.  Otherwise,
+        set to 0.
+
+      - S-bit
+
+        Set to 1 if the request is for running state data.  Otherwise,
+        set to 0.
+
+      - Request Type
+
+        14 bits specifying the request type, encoded as follows:
+
+            0x00   Request System Data
+            0x01   Request data of the listed instances
+            0x3FFF Request System Data and data of all instances
+
+      - InstanceID List
+
+        The InstanceIDs of the CIST or MSTIs; format specified in
+        Section 3.4.1.
+
+3.6.  STP Synchronization Data TLV
+
+   The pair of STP Synchronization Data TLVs are used by the sender to
+   delimit a set of TLVs that are being transmitted in response to an
+   STP Synchronization Request TLV.  The delimiting TLVs signal the
+   start and end of the synchronization data, and they associate the
+   response with its corresponding request via the Request Number field.
+   It's REQUIRED that each pair of STP Synchronization Data TLVs occur
+   in the same fragment.  When the total size of the TLVs to be
+   transmitted exceeds the maximal size of a fragment, these TLVs MUST
+   be divided into multiple sets, delimited by multiple pairs of STP
+   Synchronization Data TLVs, and filled into multiple fragments.  With
+   the Request Number, lost fragments can be identified and
+   re-requested.
+
+   The STP Synchronization Data TLVs are also used for unsolicited
+   advertisements of complete STP configuration and operational state
+   data.  The Request Number field MUST be set to 0 in this case.
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 17]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+   STP Synchronization Data 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=0x200B              |    Length                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Request Number            |    Reserved                 |S|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      - U=F=0
+
+      - Type
+
+        set to 0x200B for "STP Synchronization Data TLV"
+
+      - Length
+
+        Length of the TLV in octets excluding the U-bit, F-bit, Type,
+        and Length fields.  Always set to 4.
+
+      - Request Number
+
+        2 octets.  Unsigned integer identifying the Request Number of
+        the "STP Synchronization Request TLV" that initiated this
+        synchronization data response.
+
+      - Reserved
+
+        Reserved bits for future use.  These MUST be sent as 0 and
+        ignored on receipt.
+
+      - S
+
+        S = 0: Synchronization Data Start
+        S = 1: Synchronization Data End
+
+4.  Operations
+
+   Operational procedures for AC redundancy applications have been
+   specified in Section 9.2 of [RFC7275].  The operational procedures of
+   the ICCP STP application should follow those procedures, with the
+   changes presented in this section.
+
+4.1.  Common AC Procedures
+
+   The following changes are introduced to the generic procedures of AC
+   redundancy applications defined in Section 9.2.1 of [RFC7275].
+
+
+
+Zhang, et al.                Standards Track                   [Page 18]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+4.1.1.  Remote PE Node Failure or Isolation
+
+   When a local PE device detects that a remote PE device that is a
+   member of the same RG is no longer reachable (using the mechanisms
+   described in Section 5 of [RFC7275]), the local PE device checks if
+   it has redundancy ACs for the affected services.  If redundant ACs
+   are present, and if the local PE device has the new highest bridge
+   priority, the local PE device becomes the virtual root bridge for
+   corresponding ACs.
+
+4.1.2.  Local PE Isolation
+
+   When a PE device detects that it has been isolated from the core
+   network, then it needs to ensure that its AC redundancy mechanism
+   will change the status of all active ACs to standby.  The AC
+   redundancy application SHOULD then send an RG Application Data
+   Message in order to trigger failover to another active PE device in
+   the RG.  Note that this works only in the case of dedicated
+   interconnect (Sections 3.2.1 and 3.2.3), since ICCP will still have
+   the path to the peer, even though the PE device is isolated from the
+   MPLS core network.
+
+4.2.  ICCP STP Application Procedures
+
+   This section defines the procedures of the ICCP STP application that
+   are applicable for Ethernet ACs.
+
+4.2.1.  Initial Setup
+
+   When an RG is configured on a system that supports the ICCP STP
+   application, such systems MUST send an RG Connect Message with an STP
+   Connect TLV to each PE device that is a member of the RG.  The
+   sending PE device MUST set the A bit to 1 in that TLV if it has
+   received a corresponding STP Connect TLV from its peer PE; otherwise,
+   the sending PE device MUST set the A bit to 0.  If a PE device
+   receives an STP Connect TLV from its peer after sending its own TLV
+   with the A bit set to 0, it MUST resend the TLV with the A bit set to
+   1.  A system considers the ICCP STP application connection to be
+   operational when it has both sent and received STP Connect TLVs with
+   the A bit set to 1.  When the ICCP STP application connection between
+   a pair of PEs is operational, the two devices can start exchanging RG
+   Application Data Messages for the ICCP STP application.  This
+   involves having each PE device advertise its STP configuration and
+   operational state in an unsolicited manner.  A PE device SHOULD
+   follow the order below when advertising its STP state upon initial
+   application connection setup:
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 19]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+      - Advertise the STP System Config TLV
+      - Advertise remaining Configuration TLVs
+      - Advertise State TLVs
+
+   The update of the information contained in the State TLVs depends on
+   that in the Configuration TLVs.  By sending the TLVs in the above
+   order, the two peers may begin to update STP state as early as
+   possible in the middle of exchanging these TLVs.
+
+   A PE device MUST use a pair of STP 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 STP Connect TLV
+   that has a differing Protocol Version, it MUST follow the procedures
+   outlined in the Section 4.4.1 ("Application Versioning") of
+   [RFC7275].
+
+   After the ICCP STP application connection has been established, every
+   PE device MUST communicate its system-level configuration to its
+   peers via the use of STP System Config TLV.
+
+   When the ICCP STP application is administratively disabled on the PE,
+   or on the particular RG, the system MUST send an RG Disconnect
+   Message containing STP Disconnect TLV.
+
+4.2.2.  Configuration Synchronization
+
+   A system that supports ICCP STP application MUST synchronize the
+   configuration with other RG members.  This is achieved via the use of
+   STP Configuration TLVs.  The PEs in the RG MUST all agree on the
+   common MAC address to be associated with the virtual root bridge.  It
+   is possible to achieve this via consistent configuration on member
+   PEs.  However, in order to protect against possible
+   misconfigurations, a virtual root bridge identifier MUST be set to
+   the MAC address advertised by the PE device with the numerically
+   lowest BridgeIdentifier (i.e., the MAC address of the bridge) in the
+   RG.
+
+   Furthermore, for a given ICCP STP application, an implementation MUST
+   advertise the configuration prior to advertising its corresponding
+   state.  If a PE device receives any STP State TLV that it had not
+   learned of before via an appropriate STP Configuration TLV, then the
+   PE device MUST request synchronization of the configuration and state
+   from its peer.  If during such synchronization a PE device receives a
+   State TLV that it has not learned before, then the PE device MUST
+   send a NAK TLV for that particular TLV.  The PE device MUST NOT
+   request resynchronization in this case.
+
+
+
+Zhang, et al.                Standards Track                   [Page 20]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+4.2.3.  State Synchronization
+
+   PEs within the RG need to synchronize their state for proper STP
+   operation.  This is achieved by having each system advertise its
+   running state in STP State TLVs.  Whenever any STP parameter either
+   on the CE or PE side is changed, the system MUST transmit an updated
+   TLV for the affected STP instances.  Moreover, when the
+   administrative or operational state changes, the system MUST transmit
+   an updated State TLV to its peers.
+
+   A PE device MAY request its peer to retransmit previously advertised
+   state.  This is useful in case the PE device is recovering from a
+   soft failure and attempting to relearn state.  To request such
+   retransmissions, a PE device MUST send a set of one or more STP
+   Synchronization Request TLVs.
+
+   A PE device MUST respond to a STP Synchronization Request TLV by
+   sending the requested data in a set of one or more STP Configuration
+   or State TLVs delimited by a pair of STP Synchronization Data TLVs.
+
+   Note that the response may span across multiple RG Application Data
+   Messages, for example, when MTU limits are exceeded; however, the
+   above ordering MUST be retained across messages, and only a single
+   pair of Synchronization Data TLVs MUST be used to delimit the
+   response across all RG Application Data Messages.
+
+   A PE device MAY readvertise its STP state in an unsolicited manner.
+   This is done by sending the appropriate State TLVs delimited by a
+   pair of STP Synchronization Data TLVs and using a Request Number of
+   0.
+
+   While a PE device has sent out a synchronization request for a
+   particular PE device, it SHOULD silently ignore all TLVs that are
+   from that node, are received prior to the synchronization response,
+   and carry the same type of information being requested.  This saves
+   the system from the burden of updating state that will ultimately be
+   overwritten by the synchronization response.  Note that TLVs
+   pertaining to other systems should continue to be processed normally.
+
+   If a PE device receives a synchronization request for an instance
+   that doesn't exist or is not known to the PE, then it MUST trigger
+   the unsolicited synchronization of all information by restarting the
+   initialization.
+
+   If during the synchronization operation a PE device receives an
+   advertisement of a Node ID value that is different from the value
+   previously advertised, then the PE device MUST purge all state data
+   previously received from that peer prior to the last synchronization.
+
+
+
+Zhang, et al.                Standards Track                   [Page 21]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+4.2.4.  Failure and Recovery
+
+   When a PE device that is active for the ICCP STP application
+   encounters a core isolation fault [RFC7275], it SHOULD attempt to
+   fail over to a peer PE device that hosts the same RG.  The default
+   failover procedure is to have the failed PE device bring down the
+   link(s) towards the multihomed STP network.  This will cause the STP
+   network to reconverge and to use the other links that are connected
+   to the other PE devices in the RG.  Other procedures for triggering
+   failover are possible and are outside the scope of this document.
+
+   If the isolated PE device is the one that has the numerically lowest
+   BridgeIdentifier, PEs in the RG MUST synchronize STP Configuration
+   and State TLVs and determine a new virtual root bridge as specified
+   in Section 4.2.2.
+
+   Upon recovery from a previous fault, a PE device SHOULD NOT reclaim
+   the role of the virtual root for the STP network even if it has the
+   numerically lowest BridgeIdentifier among the RG.  This minimizes
+   traffic disruption.
+
+   Whenever the virtual root bridge changes, the STP Topology Changed
+   Instances TLV lists the instances that are affected by the change.
+   These instances MUST undergo a STP reconvergence procedure when this
+   TLV is received as defined in Section 3.4.1.
+
+5.  Security Considerations
+
+   This document specifies an application running on the channel
+   provided by ICCP [RFC7275].  The security considerations on ICCP
+   apply in this document as well.
+
+   For the ICCP STP application, an attack on a channel (running in the
+   provider's network) can break not only the ability to deliver traffic
+   across the provider's network, but also the ability to route traffic
+   within the customer's network.  That is, a careful attack on a
+   channel (such as the DoS attacks as described in [RFC7275]) can break
+   STP within the customer network.  Implementations need to provide
+   mechanisms to mitigate these types of attacks.  For example, the port
+   between the PE device and the malicious CE device may be blocked.
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 22]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+6.  IANA Considerations
+
+   The IANA maintains a top-level registry called "Pseudowire Name
+   Spaces (PWE3)".  It has a subregistry called "ICC RG Parameter
+   Types".
+
+   IANA has made 13 allocations from this registry as shown below.  IANA
+   has allocated the codepoints from the range marked for assignment by
+   IETF Review (0x2000-0x2FFF) [RFC5226].  Each assignment references
+   this document.
+
+      Parameter Type Description
+      -------------- ---------------------------------
+      0x2000         STP Connect TLV
+      0x2001         STP Disconnect TLV
+      0x2002         STP System Config TLV
+      0x2003         STP Region Name TLV
+      0x2004         STP Revision Level TLV
+      0x2005         STP Instance Priority TLV
+      0x2006         STP Configuration Digest TLV
+      0x2007         STP Topology Changed Instances TLV
+      0x2008         STP CIST Root Time TLV
+      0x2009         STP MSTI Root Time TLV
+      0x200A         STP Synchronization Request TLV
+      0x200B         STP Synchronization Data TLV
+      0x200C         STP Disconnect Cause TLV
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119,
+                DOI 10.17487/RFC2119, March 1997,
+                <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+                2003, <http://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC4762]    Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
+                Private LAN Service (VPLS) Using Label Distribution
+                Protocol (LDP) Signaling", RFC 4762,
+                DOI 10.17487/RFC4762, January 2007,
+                <http://www.rfc-editor.org/info/rfc4762>.
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 23]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+   [RFC7275]    Martini, L., Salam, S., Sajassi, A., Bocci, M.,
+                Matsushima, S., and T. Nadeau, "Inter-Chassis
+                Communication Protocol for Layer 2 Virtual Private
+                Network (L2VPN) Provider Edge (PE) Redundancy",
+                RFC 7275, DOI 10.17487/RFC7275, June 2014,
+                <http://www.rfc-editor.org/info/rfc7275>.
+
+   [802.1q]     IEEE, "IEEE Standard for Local and Metropolitan Area
+                Networks -- Bridges and Bridged Networks", IEEE Std
+                802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014.
+
+   [802.1d1998] IEEE, "Information technology -- Telecommunications and
+                information exchange between systems -- Local and
+                metropolitan area networks -- Common specifications --
+                Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE
+                Std 802.1D-1998, DOI 10.1109/IEEESTD.1998.95619, 1998.
+
+   [802.1d2004] IEEE, "IEEE Standard for Local and metropolitan area
+                networks -- Media Access Control (MAC) Bridges", IEEE
+                Std 802.1D-2004, DOI 10.1109/ieeestd.2004.94569, 2004.
+
+7.2.  Informative References
+
+   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+                DOI 10.17487/RFC5226, May 2008,
+                <http://www.rfc-editor.org/info/rfc5226>.
+
+Acknowledgements
+
+   The authors would like to thank the comments and suggestions from
+   Ignas Bagdonas, Adrian Farrel, Andrew G. Malis, Gregory Mirsky, and
+   Alexander Vainshtein.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 24]
+
+RFC 7727                 STP Application of ICCP            January 2016
+
+
+Authors' Addresses
+
+   Mingui Zhang
+   Huawei Technologies
+   No. 156 Beiqing Rd. Haidian District,
+   Beijing 100095
+   China
+
+   Email: zhangmingui@huawei.com
+
+
+   Huafeng Wen
+   Huawei Technologies
+   101 Software Avenue,
+   Nanjing 210012
+   China
+
+   Email: wenhuafeng@huawei.com
+
+
+   Jie Hu
+   China Telecom
+   Beijing Information Science & Technology Innovation Park
+   Beiqijia Town Changping District,
+   Beijing 102209
+   China
+
+   Email: hujie@ctbri.com.cn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al.                Standards Track                   [Page 25]
+