Internet Engineering Task Force (IETF)
`Request for Comments: 5810
`Category: Standards Track
`ISSN: 2070-1721
`
`A. Doria, Ed.
`Lulea University of Technology
`J. Hadi Salim, Ed.
`Znyx
`R. Haas, Ed.
`IBM
`H. Khosravi, Ed.
`Intel
`W. Wang, Ed.
`L. Dong
`Zhejiang Gongshang University
`R. Gopal
`Nokia
`J. Halpern
`March 2010
`
`Forwarding and Control Element Separation (ForCES)
`Protocol Specification
`
`Abstract
`
` This document specifies the Forwarding and Control Element Separation
` (ForCES) protocol. The ForCES protocol is used for communications
` between Control Elements(CEs) and Forwarding Elements (FEs) in a
` ForCES Network Element (ForCES NE). This specification is intended
` to meet the ForCES protocol requirements defined in RFC 3654.
` Besides the ForCES protocol, this specification also defines the
` requirements for the Transport Mapping Layer (TML).
`
`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/rfc5810.
`
`Doria, et al.
`
`Standards Track
`
`[Page 1]
`
`EX 1019 Page 1
`
`

`

`RFC 5810 ForCES March 2010
`
`Copyright Notice
`
` Copyright (c) 2010 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.
`
`Doria, et al. Standards Track [Page 2]
`
`EX 1019 Page 2
`
`

`

`RFC 5810 ForCES March 2010
`
`Table of Contents
`
` 1. Introduction ....................................................5
` 2. Terminology and Conventions .....................................6
` 2.1. Requirements Language ......................................6
` 2.2. Other Notation .............................................6
` 2.3. Integers ...................................................6
` 3. Definitions .....................................................6
` 4. Overview .......................................................10
` 4.1. Protocol Framework ........................................11
` 4.1.1. The PL .............................................13
` 4.1.2. The TML ............................................14
` 4.1.3. The FEM/CEM Interface ..............................14
` 4.2. ForCES Protocol Phases ....................................15
` 4.2.1. Pre-association ....................................16
` 4.2.2. Post-association ...................................18
` 4.3. Protocol Mechanisms .......................................19
` 4.3.1. Transactions, Atomicity, Execution, and Responses ..19
` 4.3.2. Scalability ........................................25
` 4.3.3. Heartbeat Mechanism ................................26
` 4.3.4. FE Object and FE Protocol LFBs .....................27
` 4.4. Protocol Scenarios ........................................27
` 4.4.1. Association Setup State ............................27
` 4.4.2. Association Established State or Steady State ......29
` 5. TML Requirements ...............................................31
` 5.1. TML Parameterization ......................................34
` 6. Message Encapsulation ..........................................35
` 6.1. Common Header .............................................35
` 6.2. Type Length Value (TLV) Structuring .......................40
` 6.2.1. Nested TLVs ........................................41
` 6.2.2. Scope of the T in TLV ..............................41
` 6.3. ILV .......................................................41
` 6.4. Important Protocol Encapsulations .........................42
` 6.4.1. Paths ..............................................42
` 6.4.2. Keys ...............................................42
` 6.4.3. DATA TLVs ..........................................43
` 6.4.4. Addressing LFB Entities ............................43
` 7. Protocol Construction ..........................................44
` 7.1. Discussion on Encoding ....................................48
` 7.1.1. Data Packing Rules .................................48
` 7.1.2. Path Flags .........................................49
` 7.1.3. Relation of Operational Flags with Global
` Message Flags ......................................49
` 7.1.4. Content Path Selection .............................49
` 7.1.5. LFBselect-TLV ......................................49
` 7.1.6. OPER-TLV ...........................................50
` 7.1.7. RESULT TLV .........................................52
` 7.1.8. DATA TLV ...........................................55
`
`Doria, et al. Standards Track [Page 3]
`
`EX 1019 Page 3
`
`

`

`RFC 5810 ForCES March 2010
`
` 7.1.9. SET and GET Relationship ...........................56
` 7.2. Protocol Encoding Visualization ...........................56
` 7.3. Core ForCES LFBs ..........................................59
` 7.3.1. FE Protocol LFB ....................................60
` 7.3.2. FE Object LFB ......................................63
` 7.4. Semantics of Message Direction ............................63
` 7.5. Association Messages ......................................64
` 7.5.1. Association Setup Message ..........................64
` 7.5.2. Association Setup Response Message .................66
` 7.5.3. Association Teardown Message .......................68
` 7.6. Configuration Messages ....................................69
` 7.6.1. Config Message .....................................69
` 7.6.2. Config Response Message ............................71
` 7.7. Query Messages ............................................73
` 7.7.1. Query Message ......................................73
` 7.7.2. Query Response Message .............................75
` 7.8. Event Notification Message ................................77
` 7.9. Packet Redirect Message ...................................79
` 7.10. Heartbeat Message ........................................82
` 8. High Availability Support ......................................83
` 8.1. Relation with the FE Protocol .............................83
` 8.2. Responsibilities for HA ...................................86
` 9. Security Considerations ........................................87
` 9.1. No Security ...............................................87
` 9.1.1. Endpoint Authentication ............................88
` 9.1.2. Message Authentication .............................88
` 9.2. ForCES PL and TML Security Service ........................88
` 9.2.1. Endpoint Authentication Service ....................88
` 9.2.2. Message Authentication Service .....................89
` 9.2.3. Confidentiality Service ............................89
` 10. Acknowledgments ...............................................89
` 11. References ....................................................89
` 11.1. Normative References .....................................89
` 11.2. Informative References ...................................90
` Appendix A. IANA Considerations ..................................91
` A.1. Message Type Namespace ....................................91
` A.2. Operation Selection .......................................92
` A.3. Header Flags ..............................................93
` A.4. TLV Type Namespace ........................................93
` A.5. RESULT-TLV Result Values ..................................94
` A.6. Association Setup Response ................................94
` A.7. Association Teardown Message ..............................95
` Appendix B. ForCES Protocol LFB Schema ...........................96
` B.1. Capabilities .............................................102
` B.2. Components ...............................................102
` Appendix C. Data Encoding Examples ..............................103
` Appendix D. Use Cases ...........................................107
`
`Doria, et al. Standards Track [Page 4]
`
`EX 1019 Page 4
`
`

`

`RFC 5810 ForCES March 2010
`
`1. Introduction
`
` Forwarding and Control Element Separation (ForCES) defines an
` architectural framework and associated protocols to standardize
` information exchange between the control plane and the forwarding
` plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined
` the ForCES requirements, and RFC 3746 has defined the ForCES
` framework. While there may be multiple protocols used within the
` overall ForCES architecture, the terms "ForCES protocol" and
` "protocol" as used in this document refer to the protocol used to
` standardize the information exchange between Control Elements (CEs)
` and Forwarding Elements (FEs) only.
`
` The ForCES FE model [RFC5812] presents a formal way to define FE
` Logical Function Blocks (LFBs) using XML. LFB configuration
` components, capabilities, and associated events are defined when the
` LFB is formally created. The LFBs within the FE are accordingly
` controlled in a standardized way by the ForCES protocol.
`
` This document defines the ForCES protocol specifications. The ForCES
` protocol works in a master-slave mode in which FEs are slaves and CEs
` are masters. The protocol includes commands for transport of LFB
` configuration information, association setup, status, event
` notifications, etc.
`
` Section 3 provides a glossary of terminology used in the
` specification.
`
` Section 4 provides an overview of the protocol, including a
` discussion on the protocol framework and descriptions of the Protocol
` Layer (PL), a Transport Mapping Layer (TML), and the ForCES protocol
` mechanisms. Section 4.4 describes several protocol scenarios and
` includes message exchange descriptions.
`
` While this document does not define the TML, Section 5 details the
` services that a TML MUST provide (TML requirements).
`
` The ForCES protocol defines a common header for all protocol
` messages. The header is defined in Section 6.1, while the protocol
` messages are defined in Section 7.
`
` Section 8 describes the protocol support for high-availability
` mechanisms including redundancy and fail over.
`
` Section 9 defines the security mechanisms provided by the PL and TML.
`
`Doria, et al. Standards Track [Page 5]
`
`EX 1019 Page 5
`
`

`

`RFC 5810 ForCES March 2010
`
`2. Terminology and Conventions
`
`2.1. Requirements Language
`
` 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].
`
`2.2. Other Notation
`
` In Table 1 and Table 2, the following notation is used to indicate
` multiplicity:
`
` (value)+ .... means "1 or more instances of value"
`
` (value)* .... means "0 or more instances of value"
`
`2.3. Integers
`
` All integers are to be coded as unsigned binary integers of
` appropriate length.
`
`3. Definitions
`
` This document follows the terminology defined by the ForCES
` requirements in [RFC3654] and by the ForCES framework in [RFC3746].
` The definitions be are repeated below for clarity.
`
` Addressable Entity (AE):
`
` A physical device that is directly addressable given some
` interconnect technology. For example, on IP networks, it is a device
` that can be reached using an IP address; and on a switch fabric, it
` is a device that can be reached using a switch fabric port number.
`
` Control Element (CE):
`
` A logical entity that implements the ForCES protocol and uses it to
` instruct one or more FEs on how to process packets. CEs handle
` functionality such as the execution of control and signaling
` protocols.
`
`Doria, et al. Standards Track [Page 6]
`
`EX 1019 Page 6
`
`

`

`RFC 5810 ForCES March 2010
`
` CE Manager (CEM):
`
` A logical entity responsible for generic CE management tasks. It is
` particularly used during the pre-association phase to determine with
` which FE(s) a CE should communicate. This process is called FE
` discovery and may involve the CE manager learning the capabilities of
` available FEs.
`
` Data Path:
`
` A conceptual path taken by packets within the forwarding plane inside
` an FE.
`
` Forwarding Element (FE):
`
` A logical entity that implements the ForCES protocol. FEs use the
` underlying hardware to provide per-packet processing and handling as
` directed/controlled by one or more CEs via the ForCES protocol.
`
` FE Model:
`
` A model that describes the logical processing functions of an FE.
` The FE model is defined using Logical Function Blocks (LFBs).
`
` FE Manager (FEM):
`
` A logical entity responsible for generic FE management tasks. It is
` used during the pre-association phase to determine with which CE(s)
` an FE should communicate. This process is called CE discovery and
` may involve the FE manager learning the capabilities of available
` CEs. An FE manager may use anything from a static configuration to a
` pre-association phase protocol (see below) to determine which CE(s)
` to use. Being a logical entity, an FE manager might be physically
` combined with any of the other logical entities such as FEs.
`
` ForCES Network Element (NE):
`
` An entity composed of one or more CEs and one or more FEs. To
` entities outside an NE, the NE represents a single point of
` management. Similarly, an NE usually hides its internal organization
` from external entities.
`
`Doria, et al. Standards Track [Page 7]
`
`EX 1019 Page 7
`
`

`

`RFC 5810 ForCES March 2010
`
` High Touch Capability:
`
` This term will be used to apply to the capabilities found in some
` forwarders to take action on the contents or headers of a packet
` based on content other than what is found in the IP header. Examples
` of these capabilities include quality of service (QoS) policies,
` virtual private networks, firewall, and L7 content recognition.
`
` Inter-FE Topology:
`
` See FE Topology.
`
` Intra-FE Topology:
`
` See LFB Topology.
`
` LFB (Logical Function Block):
`
` The basic building block that is operated on by the ForCES protocol.
` The LFB is a well-defined, logically separable functional block that
` resides in an FE and is controlled by the CE via the ForCES protocol.
` The LFB may reside at the FE’s data path and process packets or may
` be purely an FE control or configuration entity that is operated on
` by the CE. Note that the LFB is a functionally accurate abstraction
` of the FE’s processing capabilities, but not a hardware-accurate
` representation of the FE implementation.
`
` FE Topology:
`
` A representation of how the multiple FEs within a single NE are
` interconnected. Sometimes this is called inter-FE topology, to be
` distinguished from intra-FE topology (i.e., LFB topology).
`
` LFB Class and LFB Instance:
`
` LFBs are categorized by LFB classes. An LFB instance represents an
` LFB class (or type) existence. There may be multiple instances of
` the same LFB class (or type) in an FE. An LFB class is represented
` by an LFB class ID, and an LFB instance is represented by an LFB
` instance ID. As a result, an LFB class ID associated with an LFB
` instance ID uniquely specifies an LFB existence.
`
`Doria, et al. Standards Track [Page 8]
`
`EX 1019 Page 8
`
`

`

`RFC 5810 ForCES March 2010
`
` LFB Meta Data:
`
` Meta data is used to communicate per-packet state from one LFB to
` another, but is not sent across the network. The FE model defines
` how such meta data is identified, produced, and consumed by the LFBs.
` It defines the functionality but not how meta data is encoded within
` an implementation.
`
` LFB Component:
`
` Operational parameters of the LFBs that must be visible to the CEs
` are conceptualized in the FE model as the LFB components. The LFB
` components include, for example, flags, single parameter arguments,
` complex arguments, and tables that the CE can read and/or write via
` the ForCES protocol (see below).
`
` LFB Topology:
`
` Representation of how the LFB instances are logically interconnected
` and placed along the data path within one FE. Sometimes it is also
` called intra-FE topology, to be distinguished from inter-FE topology.
`
` Pre-association Phase:
`
` The period of time during which an FE manager and a CE manager are
` determining which FE(s) and CE(s) should be part of the same network
` element.
`
` Post-association Phase:
`
` The period of time during which an FE knows which CE is to control it
` and vice versa. This includes the time during which the CE and FE
` are establishing communication with one another.
`
` ForCES Protocol:
`
` While there may be multiple protocols used within the overall ForCES
` architecture, the terms "ForCES protocol" and "protocol" refer to the
` Fp reference points in the ForCES framework in [RFC3746]. This
` protocol does not apply to CE-to-CE communication, FE-to-FE
` communication, or communication between FE and CE managers.
` Basically, the ForCES protocol works in a master-slave mode in which
` FEs are slaves and CEs are masters. This document defines the
` specifications for this ForCES protocol.
`
`Doria, et al. Standards Track [Page 9]
`
`EX 1019 Page 9
`
`

`

`RFC 5810 ForCES March 2010
`
` ForCES Protocol Layer (ForCES PL):
`
` A layer in the ForCES protocol architecture that defines the ForCES
` protocol messages, the protocol state transfer scheme, and the ForCES
` protocol architecture itself (including requirements of ForCES TML as
` shown below). Specifications of ForCES PL are defined by this
` document.
`
` ForCES Protocol Transport Mapping Layer (ForCES TML):
`
` A layer in ForCES protocol architecture that uses the capabilities of
` existing transport protocols to specifically address protocol message
` transportation issues, such as how the protocol messages are mapped
` to different transport media (like TCP, IP, ATM, Ethernet, etc.), and
` how to achieve and implement reliability, multicast, ordering, etc.
` The ForCES TML specifications are detailed in separate ForCES
` documents, one for each TML.
`
`4. Overview
`
` The reader is referred to the framework document [RFC3746], and in
` particular, Sections 3 and 4, for an architectural overview and an
` explanation of how the ForCES protocol fits in. There may be some
` content overlap between the framework document and this section in
` order to provide clarity. This document is authoritative on the
` protocol, whereas [RFC3746] is authoritative on the architecture.
`
`Doria, et al. Standards Track [Page 10]
`
`EX 1019 Page 10
`
`

`

`RFC 5810 ForCES March 2010
`
`4.1. Protocol Framework
`
` Figure 1 below is reproduced from the framework document for clarity.
` It shows an NE with two CEs and two FEs.
`
` ---------------------------------------
` | ForCES Network Element |
` -------------- Fc | -------------- -------------- |
` | CE Manager |---------+-| CE 1 |------| CE 2 | |
` -------------- | | | Fr | | |
` | | -------------- -------------- |
` | Fl | | | Fp / |
` | | Fp| |----------| / |
` | | | |/ |
` | | | | |
` | | | Fp /|----| |
` | | | /--------/ | |
` -------------- Ff | -------------- -------------- |
` | FE Manager |---------+-| FE 1 | Fi | FE 2 | |
` -------------- | | |------| | |
` | -------------- -------------- |
` | | | | | | | | | |
` ----+--+--+--+----------+--+--+--+-----
` | | | | | | | |
` | | | | | | | |
` Fi/f Fi/f
`
` Fp: CE-FE interface
` Fi: FE-FE interface
` Fr: CE-CE interface
` Fc: Interface between the CE manager and a CE
` Ff: Interface between the FE manager and an FE
` Fl: Interface between the CE manager and the FE manager
` Fi/f: FE external interface
`
` Figure 1: ForCES Architectural Diagram
`
` The ForCES protocol domain is found in the Fp reference points. The
` Protocol Element configuration reference points, Fc and Ff, also play
` a role in the booting up of the ForCES protocol. The protocol
` element configuration (indicated by reference points Fc, Ff, and Fl
` in [RFC3746]) is out of scope of the ForCES protocol but is touched
` on in this document in discussion of FEM and CEM since it is an
` integral part of the protocol pre-association phase.
`
`Doria, et al. Standards Track [Page 11]
`
`EX 1019 Page 11
`
`

`

`RFC 5810 ForCES March 2010
`
` Figure 2 below shows further breakdown of the Fp interfaces by means
` of the example of an MPLS QoS-enabled Network Element.
`
` -------------------------------------------------
` | | | | | | |
` |OSPF |RIP |BGP |RSVP |LDP |. . . |
` | | | | | | |
` ------------------------------------------------- CE
` | ForCES Interface |
` -------------------------------------------------
` ^ ^
` | |
` ForCES | |data
` control | |packets
` messages| |(e.g., routing packets)
` | |
` v v
` -------------------------------------------------
` | ForCES Interface |
` ------------------------------------------------- FE
` | | | | | | |
` |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
` | | | | |fier | |
` -------------------------------------------------
`
` Figure 2: Examples of CE and FE Functions
`
` The ForCES interface shown in Figure 2 constitutes two pieces: the PL
` and the TML.
`
`Doria, et al. Standards Track [Page 12]
`
`EX 1019 Page 12
`
`

`

`RFC 5810 ForCES March 2010
`
` This is depicted in Figure 3 below.
`
` +------------------------------------------------
` | CE PL |
` +------------------------------------------------
` | CE TML |
` +------------------------------------------------
` ^
` |
` ForCES | (i.e., ForCES data + control
` PL | packets )
` messages |
` over |
` specific |
` TML |
` encaps |
` and |
` transport |
` |
` v
` +------------------------------------------------
` | FE TML |
` +------------------------------------------------
` | FE PL |
` +------------------------------------------------
`
` Figure 3: ForCES Interface
`
` The PL is in fact the ForCES protocol. Its semantics and message
` layout are defined in this document. The TML layer is necessary to
` connect two ForCES PLs as shown in Figure 3 above. The TML is out of
` scope for this document but is within scope of ForCES. This document
` defines requirements the PL needs the TML to meet.
`
` Both the PL and the TML are standardized by the IETF. While only one
` PL is defined, different TMLs are expected to be standardized. To
` interoperate, the TML at the CE and FE are expected to conform to the
` same definition.
`
` On transmit, the PL delivers its messages to the TML. The local TML
` delivers the message to the destination TML. On receive, the TML
` delivers the message to its destination PL.
`
`4.1.1. The PL
`
` The PL is common to all implementations of ForCES and is standardized
` by the IETF as defined in this document. The PL is responsible for
` associating an FE or CE to an NE. It is also responsible for tearing
`
`Doria, et al. Standards Track [Page 13]
`
`EX 1019 Page 13
`
`

`

`RFC 5810 ForCES March 2010
`
` down such associations. An FE uses the PL to transmit various
` subscribed-to events to the CE PL as well as to respond to various
` status requests issued from the CE PL. The CE configures both the FE
` and associated LFBs’ operational parameters using the PL. In
` addition, the CE may send various requests to the FE to activate or
` deactivate it, reconfigure its HA parameterization, subscribe to
` specific events, etc. More details can be found in Section 7.
`
`4.1.2. The TML
`
` The TML transports the PL messages. The TML is where the issues of
` how to achieve transport-level reliability, congestion control,
` multicast, ordering, etc. are handled. It is expected that more than
` one TML will be standardized. The various possible TMLs could vary
` their implementations based on the capabilities of underlying media
` and transport. However, since each TML is standardized,
` interoperability is guaranteed as long as both endpoints support the
` same TML. All ForCES protocol layer implementations MUST be portable
` across all TMLs, because all TMLs MUST have the top-edge semantics
` defined in this document.
`
`4.1.3. The FEM/CEM Interface
`
` The FEM and CEM components, although valuable in the setup and
` configurations of both the PL and TML, are out of scope of the ForCES
` protocol. The best way to think of them is as configurations/
` parameterizations for the PL and TML before they become active (or
` even at runtime based on implementation). In the simplest case, the
` FE or CE reads a static configuration file. RFC 3746 has a more
` detailed description on how the FEM and CEM could be used. The pre-
` association phase, where the CEM and FEM can be used, are described
` briefly in Section 4.2.1.
`
` An example of typical things the FEM/CEM could configure would be
` TML-specific parameterizations such as:
`
` a. How the TML connection should happen (for example, what IP
` addresses to use, transport modes, etc.)
`
` b. The ID for the FE (FEID) or CE (CEID) (which would also be issued
` during the pre-association phase)
`
` c. Security parameterization such as keys, etc.
`
` d. Connection association parameters
`
`Doria, et al. Standards Track [Page 14]
`
`EX 1019 Page 14
`
`

`

`RFC 5810 ForCES March 2010
`
` An example of connection association parameters might be:
`
` o simple parameters: send up to 3 association messages every 1
` second
`
` o complex parameters: send up to 4 association messages with
` increasing exponential timeout
`
`4.2. ForCES Protocol Phases
`
` ForCES, in relation to NEs, involves two phases: the pre-association
` phase where configuration/initialization/bootup of the TML and PL
` layer happens, and the post-association phase where the ForCES
` protocol operates to manipulate the parameters of the FEs.
`
` CE sends Association Setup
` +---->--->------------>---->---->---->------->----+
` | Y
` ^ |
` | Y
` +---+-------+ +-------------+
` |FE pre- | | FE post- |
` |association| CE sends Association Teardown | association |
` |phase |<------- <------<-----<------<-------+ phase |
` | | | |
` +-----------+ +-------------+
` ^ Y
` | |
` +-<---<------<-----<------<----<---------<------+
` FE loses association
`
` Figure 4: The FE Protocol Phases
`
` In the mandated case, once associated, the FE may forward packets
` depending on the configuration of its specific LFBs. An FE that is
` associated to a CE will continue sending packets until it receives an
` Association Teardown Message or until it loses association. An
` unassociated FE MAY continue sending packets when it has a high
` availability capability. The extra details are explained in
` Section 8 and not discussed here to allow for a clear explanation of
` the basics.
`
` The FE state transitions are controlled by means of the FE Object LFB
` FEState component, which is defined in [RFC5812], Section 5.1, and
` also explained in Section 7.3.2.
`
`Doria, et al. Standards Track [Page 15]
`
`EX 1019 Page 15
`
`

`

`RFC 5810 ForCES March 2010
`
` The FE initializes in the FEState OperDisable. When the FE is ready
` to process packets in the data path, it transitions itself to the
` OperEnable state.
`
` The CE may decide to pause the FE after it already came up as
` OperEnable. It does this by setting the FEState to AdminDisable.
` The FE stays in the AdminDisable state until it is explicitly
` configured by the CE to transition to the OperEnable state.
`
` When the FE loses its association with the CE, it may go into the
` pre-association phase depending on the programmed policy. For the FE
` to properly complete the transition to the AdminDisable state, it
` MUST stop packet forwarding and this may impact multiple LFBS. How
` this is achieved is outside the scope of this specification.
`
`4.2.1. Pre-associati