draft-ietf-forces-protocol-22.txt   rfc5810.txt 
Network Working Group A. Doria (Ed.) Internet Engineering Task Force (IETF) A. Doria, Ed.
Internet-Draft Lulea University of Technology Request for Comments: 5810 Lulea University of Technology
Intended status: Standards Track R. Haas (Ed.) Category: Standards Track J. Hadi Salim, Ed.
Expires: September 3, 2009 IBM ISSN: 2070-1721 Znyx
J. Hadi Salim (Ed.) R. Haas, Ed.
Znyx IBM
H. Khosravi (Ed.) H. Khosravi, Ed.
Intel Intel
W. M. Wang (Ed.) W. Wang, Ed.
L. Dong
Zhejiang Gongshang University Zhejiang Gongshang University
R. Gopal
Nokia
J. Halpern
March 2010
March 2, 2009 Forwarding and Control Element Separation (ForCES)
Protocol Specification
ForCES Protocol Specification
draft-ietf-forces-protocol-22.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 3, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies the Forwarding and Control Element Separation This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications (ForCES) protocol. The ForCES protocol is used for communications
between Control Elements(CEs) and Forwarding Elements (FEs) in a between Control Elements(CEs) and Forwarding Elements (FEs) in a
ForCES Network Element (ForCES NE). This specification is intended ForCES Network Element (ForCES NE). This specification is intended
to meet the ForCES protocol requirements defined in RFC3654. Besides to meet the ForCES protocol requirements defined in RFC 3654.
the ForCES protocol, this specification also defines the requirements Besides the ForCES protocol, this specification also defines the
for the Transport Mapping Layer (TML). requirements for the Transport Mapping Layer (TML).
Authors
The participants in the ForCES Protocol Team, primary co-authors and
co-editors, of this protocol specification, are:
Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea
University of Technology), Ram Gopal (Nokia), Robert Haas (IBM),
Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang
(Zhejiang Gongshang University). Special acknowledgement goes to
Joel Halpern who has done extensive editing in support of congruence
between the model and this protocol specification. Without his
participation and persistence, this specification might never have
been completed.
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 7
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 7
1.3. Integers . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12
4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18
4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20
4.3.1. Transactions, Atomicity, Execution and Responses . . 20
4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26
4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27
4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27
4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28
4.4.1. Association Setup State . . . . . . . . . . . . . . . 28
4.4.2. Association Established state or Steady State . . . . 29
5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32
5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 35
6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 36
6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 41
6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 42
6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 42
6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4. Important Protocol encapsulations . . . . . . . . . . . . 43
6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 43
6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 44
6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 44
7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 46
7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 50
7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 50
7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 50
7.1.3. Relation of operational flags with global message
flags . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.4. Content Path Selection . . . . . . . . . . . . . . . 51
7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 51
7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 52
7.1.7. RESULT TLV . . . . . . . . . . . . . . . . . . . . . 54
7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 57
7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 58
7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 59
7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 62
7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 63
7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 66
7.4. Semantics of Message Direction . . . . . . . . . . . . . 66
7.5. Association Messages . . . . . . . . . . . . . . . . . . 67
7.5.1. Association Setup Message . . . . . . . . . . . . . . 67
7.5.2. Association Setup Response Message . . . . . . . . . 69
7.5.3. Association Teardown Message . . . . . . . . . . . . 70
7.6. Configuration Messages . . . . . . . . . . . . . . . . . 72
7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 72
7.6.2. Config Response Message . . . . . . . . . . . . . . . 74
7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 76
7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 76
7.7.2. Query Response Message . . . . . . . . . . . . . . . 78
7.8. Event Notification Message . . . . . . . . . . . . . . . 80
7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 82
7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 85
8. High Availability Support . . . . . . . . . . . . . . . . . . 87
8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 87
8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 90
9. Security Considerations . . . . . . . . . . . . . . . . . . . 91
9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 91
9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 92
9.1.2. Message Authentication . . . . . . . . . . . . . . . 92
9.2. ForCES PL and TML security service . . . . . . . . . . . 92
9.2.1. Endpoint authentication service . . . . . . . . . . . 92
9.2.2. Message authentication service . . . . . . . . . . . 93
9.2.3. Confidentiality service . . . . . . . . . . . . . . . 93
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1. Normative References . . . . . . . . . . . . . . . . . . 95
11.2. Informational References . . . . . . . . . . . . . . . . 95
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 96
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 96
A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 97
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 98
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 98
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 98
A.6. Association Setup Response . . . . . . . . . . . . . . . 99
A.7. Association Teardown Message . . . . . . . . . . . . . . 100
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 101
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 106
B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 106
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 107
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 111
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 126
1. Terminology and Conventions Status of This Memo
1.1. Requirements Language This is an Internet Standards Track document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is a product of the Internet Engineering Task Force
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this (IETF). It represents the consensus of the IETF community. It has
document are to be interpreted as described in RFC 2119 [RFC2119]. 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.
1.2. Other Notation 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.
In Table 1 and Table 2 the following notation is used to indicate Copyright Notice
multiplicity:
(value)+ .... means "1 or more instance of value" Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
(value)* .... means "0 or more instance of value" 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.
1.3. Integers Table of Contents
All integers are to be coded as unsigned binary integers of 1. Introduction ....................................................5
appropriate length. 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
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
2. Introduction 1. Introduction
Forwarding and Control Element Separation (ForCES) defines an Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined
the ForCES requirements, and RFC 3746 has defined the ForCES the ForCES requirements, and RFC 3746 has defined the ForCES
framework. While there may be multiple protocols used within the framework. While there may be multiple protocols used within the
overall ForCES architecture, the term "ForCES protocol" and overall ForCES architecture, the terms "ForCES protocol" and
"protocol" as used in this document refers to the protocol used to "protocol" as used in this document refer to the protocol used to
standardize the information exchange between Control Elements (CEs) standardize the information exchange between Control Elements (CEs)
and Forwarding Elements (FEs) only. and Forwarding Elements (FEs) only.
The ForCES FE model [FE-MODEL] presents a formal way to define FE The ForCES FE model [RFC5812] presents a formal way to define FE
Logical Function Blocks (LFBs) using XML. LFB configuration Logical Function Blocks (LFBs) using XML. LFB configuration
components, capabilities, and associated events are defined when the components, capabilities, and associated events are defined when the
LFB is formally created. The LFBs within the FE are accordingly LFB is formally created. The LFBs within the FE are accordingly
controlled in a standardized way by the ForCES protocol. controlled in a standardized way by the ForCES protocol.
This document defines the ForCES protocol specifications. The ForCES This document defines the ForCES protocol specifications. The ForCES
protocol works in a master-slave mode in which FEs are slaves and CEs protocol works in a master-slave mode in which FEs are slaves and CEs
are masters. The protocol includes commands for transport of Logical are masters. The protocol includes commands for transport of LFB
Function Block (LFB) configuration information, association setup, configuration information, association setup, status, event
status, and event notifications, etc. notifications, etc.
Section 3 provides a glossary of terminology used in the Section 3 provides a glossary of terminology used in the
specification. specification.
Section 4 provides an overview of the protocol, including a Section 4 provides an overview of the protocol, including a
discussion on the protocol framework, descriptions of the Protocol discussion on the protocol framework and descriptions of the Protocol
Layer (PL) and a Transport Mapping Layer (TML), as well as of the Layer (PL), a Transport Mapping Layer (TML), and the ForCES protocol
ForCES protocol mechanisms. Section 4.4 describes several Protocol mechanisms. Section 4.4 describes several protocol scenarios and
scenarios and includes message exchange descriptions. includes message exchange descriptions.
While this document does not define the TML, Section 5 details the While this document does not define the TML, Section 5 details the
services that a TML MUST provide (TML requirements). services that a TML MUST provide (TML requirements).
The ForCES protocol defines a common header for all protocol The ForCES protocol defines a common header for all protocol
messages. The header is defined in Section 6.1, while the protocol messages. The header is defined in Section 6.1, while the protocol
messages are defined in Section 7. messages are defined in Section 7.
Section 8 describes the protocol support for high availability Section 8 describes the protocol support for high-availability
mechanisms including redundancy and fail over. mechanisms including redundancy and fail over.
Section 9 defines the security mechanisms provided by the PL and TML. Section 9 defines the security mechanisms provided by the PL and TML.
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 3. Definitions
This document follows the terminology defined by the ForCES This document follows the terminology defined by the ForCES
Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. requirements in [RFC3654] and by the ForCES framework in [RFC3746].
The definitions below are repeated below for clarity. The definitions be are repeated below for clarity.
Addressable Entity (AE) - A physical device that is directly Addressable Entity (AE):
addressable given some interconnect technology. For example, on IP
networks, it is a device which can be reached using an IP address;
and on a switch fabric, it is a device which can be reached using a
switch fabric port number.
Control Element (CE) - A logical entity that implements the ForCES A physical device that is directly addressable given some
protocol and uses it to instruct one or more FEs on how to process interconnect technology. For example, on IP networks, it is a device
packets. CEs handle functionality such as the execution of control that can be reached using an IP address; and on a switch fabric, it
and signaling protocols. is a device that can be reached using a switch fabric port number.
CE Manager (CEM) - A logical entity responsible for generic CE Control Element (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.
Datapath - A conceptual path taken by packets within the forwarding A logical entity that implements the ForCES protocol and uses it to
plane inside an FE. instruct one or more FEs on how to process packets. CEs handle
functionality such as the execution of control and signaling
protocols.
Forwarding Element (FE) - A logical entity that implements the ForCES CE Manager (CEM):
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 A logical entity responsible for generic CE management tasks. It is
an FE. The FE model is defined using Logical Function Blocks (LFBs). 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.
FE Manager (FEM) - A logical entity responsible for generic FE Data Path:
management tasks. It is used during 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 A conceptual path taken by packets within the forwarding plane inside
and one or more FEs. To entities outside an NE, the NE represents a an FE.
single point of management. Similarly, an NE usually hides its
internal organization from external entities.
High Touch Capability - This term will be used to apply to the Forwarding Element (FE):
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 policies, virtual private networks, firewall, and L7 content
recognition.
Inter-FE Topology - See FE Topology. 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.
Intra-FE Topology - See LFB Topology. FE Model:
LFB (Logical Function Block) - The basic building block that is A model that describes the logical processing functions of an FE.
operated on by the ForCES protocol. The LFB is a well defined, The FE model is defined using Logical Function Blocks (LFBs).
logically separable functional block that resides in an FE and is
controlled by the CE via ForCES protocol. The LFB may reside at the
FE's datapath 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 FE Manager (FEM):
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 A logical entity responsible for generic FE management tasks. It is
LFB Instance represents an LFB Class (or Type) existence. There may used during the pre-association phase to determine with which CE(s)
be multiple instances of the same LFB Class (or Type) in an FE. An an FE should communicate. This process is called CE discovery and
LFB Class is represented by an LFB Class ID, and an LFB Instance is may involve the FE manager learning the capabilities of available
represented by an LFB Instance ID. As a result, an LFB Class ID CEs. An FE manager may use anything from a static configuration to a
associated with an LFB Instance ID uniquely specifies an LFB pre-association phase protocol (see below) to determine which CE(s)
existence. to use. Being a logical entity, an FE manager might be physically
combined with any of the other logical entities such as FEs.
LFB Metadata - Metadata is used to communicate per-packet state from ForCES Network Element (NE):
one LFB to another, but is not sent across the network. The FE model
defines how such metadata is identified, produced and consumed by the
LFBs. It defines the functionality but not how metadata is encoded
within an implementation.
LFB Attribute - Operational parameters of the LFBs that must be An entity composed of one or more CEs and one or more FEs. To
visible to the CEs are conceptualized in the FE model as the LFB entities outside an NE, the NE represents a single point of
attributes. The LFB attributes include, for example, flags, single management. Similarly, an NE usually hides its internal organization
parameter arguments, complex arguments, and tables that the CE can from external entities.
read and/or write via the ForCES protocol (see below).
LFB Topology - Representation of how the LFB instances are logically High Touch Capability:
interconnected and placed along the datapath within one FE.
Sometimes it is also called intra-FE topology, to be distinguished This term will be used to apply to the capabilities found in some
from inter-FE topology. 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.
Pre-association Phase - The period of time during which an FE Manager Inter-FE Topology:
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 See FE Topology.
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 Intra-FE Topology:
the overall ForCES architecture, the term "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 to 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.
ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol See LFB Topology.
architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as 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 LFB (Logical Function Block):
ForCES protocol architecture that uses the capabilities of existing
transport protocols to specifically address protocol message 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.
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.
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 transportation issues, such as how the protocol messages are mapped
to different transport media (like TCP, IP, ATM, Ethernet, etc), and to different transport media (like TCP, IP, ATM, Ethernet, etc.), and
how to achieve and implement reliability, multicast, ordering, etc. how to achieve and implement reliability, multicast, ordering, etc.
The ForCES TML specifications are detailed in separate ForCES The ForCES TML specifications are detailed in separate ForCES
documents, one for each TML. documents, one for each TML.
4. Overview 4. Overview
The reader is referred to the Framework document [RFC3746], and in The reader is referred to the framework document [RFC3746], and in
particular sections 3 and 4, for an architectural overview and an particular, Sections 3 and 4, for an architectural overview and an
explanation of how the ForCES protocol fits in. There may be some explanation of how the ForCES protocol fits in. There may be some
content overlap between the framework document and this section in content overlap between the framework document and this section in
order to provide clarity. This document is authoritative on the order to provide clarity. This document is authoritative on the
protocol whereas [RFC3746] is authoritative on the architecture. protocol, whereas [RFC3746] is authoritative on the architecture.
4.1. Protocol Framework 4.1. Protocol Framework
Figure 1 below is reproduced from the Framework document for clarity. Figure 1 below is reproduced from the framework document for clarity.
It shows a NE with two CEs and two FEs. It shows an NE with two CEs and two FEs.
--------------------------------------- ---------------------------------------
| ForCES Network Element | | ForCES Network Element |
-------------- Fc | -------------- -------------- | -------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | | | CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | | -------------- | | | Fr | | |
| | -------------- -------------- | | | -------------- -------------- |
| Fl | | | Fp / | | Fl | | | Fp / |
| | Fp| |----------| / | | | Fp| |----------| / |
| | | |/ | | | | |/ |
skipping to change at page 12, line 44 skipping to change at page 11, line 35
| -------------- -------------- | | -------------- -------------- |
| | | | | | | | | | | | | | | | | | | |
----+--+--+--+----------+--+--+--+----- ----+--+--+--+----------+--+--+--+-----
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Fi/f Fi/f Fi/f Fi/f
Fp: CE-FE interface Fp: CE-FE interface
Fi: FE-FE interface Fi: FE-FE interface
Fr: CE-CE interface Fr: CE-CE interface
Fc: Interface between the CE Manager and a CE Fc: Interface between the CE manager and a CE
Ff: Interface between the FE Manager and an FE Ff: Interface between the FE manager and an FE
Fl: Interface between the CE Manager and the FE Manager Fl: Interface between the CE manager and the FE manager
Fi/f: FE external interface Fi/f: FE external interface
Figure 1: ForCES Architectural Diagram Figure 1: ForCES Architectural Diagram
The ForCES protocol domain is found in the Fp Reference Points. The The ForCES protocol domain is found in the Fp reference points. The
Protocol Element configuration reference points, Fc and Ff also play Protocol Element configuration reference points, Fc and Ff, also play
a role in the booting up of the ForCES Protocol. The protocol a role in the booting up of the ForCES protocol. The protocol
element configuration (indicated by reference points Fc, Ff, and Fl element configuration (indicated by reference points Fc, Ff, and Fl
in [RFC3746] ) is out of scope of the ForCES protocol but is touched 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 on in this document in discussion of FEM and CEM since it is an
integral part of the protocol pre-association phase. integral part of the protocol pre-association phase.
Figure 2 below shows further breakdown of the Fp interfaces by means Figure 2 below shows further breakdown of the Fp interfaces by means
of the example of an MPLS QoS enabled Network Element. of the example of an MPLS QoS-enabled Network Element.
------------------------------------------------- -------------------------------------------------
| | | | | | | | | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . | |OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | | | | | | | | |
------------------------------------------------- CE ------------------------------------------------- CE
| ForCES Interface | | ForCES Interface |
------------------------------------------------- -------------------------------------------------
^ ^ ^ ^
| | | |
skipping to change at page 13, line 35 skipping to change at page 12, line 30
| | | |
v v v v
------------------------------------------------- -------------------------------------------------
| ForCES Interface | | ForCES Interface |
------------------------------------------------- FE ------------------------------------------------- FE
| | | | | | | | | | | | | |
|LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
| | | | |fier | | | | | | |fier | |
------------------------------------------------- -------------------------------------------------
Figure 2: Examples of CE and FE functions Figure 2: Examples of CE and FE Functions
The ForCES Interface shown in Figure 2 constitutes two pieces: the PL The ForCES interface shown in Figure 2 constitutes two pieces: the PL
and the TML. and the TML.
This is depicted in Figure 3 below. This is depicted in Figure 3 below.
+------------------------------------------------ +------------------------------------------------
| CE PL | | CE PL |
+------------------------------------------------ +------------------------------------------------
| CE TML | | CE TML |
+------------------------------------------------ +------------------------------------------------
^ ^
| |
ForCES | (i.e ForCES data + control ForCES | (i.e., ForCES data + control
PL | packets ) PL | packets )
messages | messages |
over | over |
specific | specific |
TML | TML |
encaps | encaps |
and | and |
transport | transport |
| |
v v
+------------------------------------------------ +------------------------------------------------
| FE TML | | FE TML |
+------------------------------------------------ +------------------------------------------------
| FE PL | | FE PL |
+------------------------------------------------ +------------------------------------------------
Figure 3: ForCES Interface Figure 3: ForCES Interface
The PL is in fact the ForCES protocol. Its semantics and message The PL is in fact the ForCES protocol. Its semantics and message
layout are defined in this document. The TML Layer is necessary to 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 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 scope for this document but is within scope of ForCES. This document
defines requirements the PL needs the TML to meet. defines requirements the PL needs the TML to meet.
Both the PL and the TML are standardized by the IETF. While only one 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 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 interoperate, the TML at the CE and FE are expected to conform to the
same definition. same definition.
On transmit, the PL delivers its messages to the TML. The local TML 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 the destination TML. On receive, the TML
delivers the message to its destination PL. delivers the message to its destination PL.
4.1.1. The PL 4.1.1. The PL
The PL is common to all implementations of ForCES and is standardized 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 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 associating an FE or CE to an NE. It is also responsible for tearing
down such associations. An FE uses the PL to transmit various 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 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 status requests issued from the CE PL. The CE configures both the FE
and associated LFBs' operational parameters using the PL. In and associated LFBs' operational parameters using the PL. In
addition the CE may send various requests to the FE to activate or addition, the CE may send various requests to the FE to activate or
deactivate it, reconfigure its HA parameterization, subscribe to deactivate it, reconfigure its HA parameterization, subscribe to
specific events etc. More details can be found in Section 7. specific events, etc. More details can be found in Section 7.
4.1.2. The TML 4.1.2. The TML
The TML transports the PL messages. The TML is where the issues of The TML transports the PL messages. The TML is where the issues of
how to achieve transport level reliability, congestion control, how to achieve transport-level reliability, congestion control,
multicast, ordering, etc. are handled. It is expected that more than multicast, ordering, etc. are handled. It is expected that more than
one TML will be standardized. The various possible TMLs could vary one TML will be standardized. The various possible TMLs could vary
their implementations based on the capabilities of underlying media their implementations based on the capabilities of underlying media
and transport. However, since each TML is standardized, and transport. However, since each TML is standardized,
interoperability is guaranteed as long as both endpoints support the interoperability is guaranteed as long as both endpoints support the
same TML. All ForCES Protocol Layer implementations MUST be portable same TML. All ForCES protocol layer implementations MUST be portable
across all TMLs, because all TMLs MUST have the top edge semantics across all TMLs, because all TMLs MUST have the top-edge semantics
defined in this document. defined in this document.
4.1.3. The FEM/CEM Interface 4.1.3. The FEM/CEM Interface
The FEM and CEM components, although valuable in the setup and 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 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/ protocol. The best way to think of them is as configurations/
parameterizations for the PL and TML before they become active (or parameterizations for the PL and TML before they become active (or
even at runtime based on implementation). In the simplest case, the even at runtime based on implementation). In the simplest case, the
FE or CE reads a static configuration file. RFC 3746 has a more 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- 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 association phase, where the CEM and FEM can be used, are described
briefly in Section 4.2.1. briefly in Section 4.2.1.
An example of typical things the FEM/CEM could configure would be TML An example of typical things the FEM/CEM could configure would be
specific parameterizations such as: TML-specific parameterizations such as:
a. How the TML connection should happen (for example what IP a. How the TML connection should happen (for example, what IP
addresses to use, transport modes etc); addresses to use, transport modes, etc.)
b. The ID for the FE (FEID) or CE (CEID) (which would also be issued b. The ID for the FE (FEID) or CE (CEID) (which would also be issued
during the pre-association phase). during the pre-association phase)
c. Security parameterization such as keys etc. c. Security parameterization such as keys, etc.
d. Connection association parameters d. Connection association parameters
An example of connection association parameters might be:
Example of connection association parameters this might be:
o simple parameters: send up to 3 association messages every 1 o simple parameters: send up to 3 association messages every 1
second second
o complex parameters: send up to 4 association messages with o complex parameters: send up to 4 association messages with
increasing exponential timeout increasing exponential timeout
4.2. ForCES Protocol Phases 4.2. ForCES Protocol Phases
ForCES, in relation to NEs, involves two phases: the pre-association ForCES, in relation to NEs, involves two phases: the pre-association
phase, where configuration/initialization/bootup of the TML and PL phase where configuration/initialization/bootup of the TML and PL
layer happens, and the post-association phase where the ForCES layer happens, and the post-association phase where the ForCES
protocol operates to manipulate the parameters of the FEs. protocol operates to manipulate the parameters of the FEs.
CE sends Association Setup CE sends Association Setup
+---->--->------------>---->---->---->------->----+ +---->--->------------>---->---->---->------->----+
| Y | Y
^ | ^ |
| Y | Y
+---+-------+ +-------------+ +---+-------+ +-------------+
|FE Pre- | | FE Post- | |FE pre- | | FE post- |
|Association| CE sends Association Teardown | Association | |association| CE sends Association Teardown | association |
|Phase |<------- <------<-----<------<-------+ Phase | |phase |<------- <------<-----<------<-------+ phase |
| | | | | | | |
+-----------+ +-------------+ +-----------+ +-------------+
^ Y ^ Y
| | | |
+-<---<------<-----<------<----<---------<------+ +-<---<------<-----<------<----<---------<------+
FE loses association FE loses association
Figure 4: The FE Protocol Phases Figure 4: The FE Protocol Phases
In the mandated case, once associated, the FE may forward packets In the mandated case, once associated, the FE may forward packets
depending on the configuration of its specific LFBs. An FE which is depending on the configuration of its specific LFBs. An FE that is
associated to a CE will continue sending packets until it receives an associated to a CE will continue sending packets until it receives an
Association teardown message or until it loses association. An Association Teardown Message or until it loses association. An
unassociated FE MAY continue sending packets when it has a high unassociated FE MAY continue sending packets when it has a high
availability capability. The extra details are explained in availability capability. The extra details are explained in
Section 8 and not discussed here to allow for a clear explanation of Section 8 and not discussed here to allow for a clear explanation of
the basics. the basics.
The FE state transitions are controlled by means of the FE Object LFB The FE state transitions are controlled by means of the FE Object LFB
FEState component, which is defined in [FE-MODEL] section 5.1 and FEState component, which is defined in [RFC5812], Section 5.1, and
also explained in Section 7.3.2. also explained in Section 7.3.2.
The FE initializes in the FEState OperDisable. When the FE is ready The FE initializes in the FEState OperDisable. When the FE is ready
to process packets in the data path it transitions itself to the to process packets in the data path, it transitions itself to the
OperEnable state. OperEnable state.
The CE may decide to pause the FE after it already came up as The CE may decide to pause the FE after it already came up as
OperEnable. It does this by setting the FEState to AdminDisable. OperEnable. It does this by setting the FEState to AdminDisable.
The FE stays in the AdminDisable state until it is explicitly The FE stays in the AdminDisable state until it is explicitly
configured by the CE to transition to the OperEnable state. 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- When the FE loses its association with the CE, it may go into the
association phase depending on the programmed policy. For the FE to pre-association phase depending on the programmed policy. For the FE
properly complete the transition to the AdminDisable state, it MUST to properly complete the transition to the AdminDisable state, it
stop Packet forwarding and this may impact multiple LFBS. How this MUST stop packet forwarding and this may impact multiple LFBS. How
is achieved is outside the scope of this specification. this is achieved is outside the scope of this specification.
4.2.1. Pre-association 4.2.1. Pre-association
The ForCES interface is configured during the pre-association phase. The ForCES interface is configured during the pre-association phase.
In a simple setup, the configuration is static and is typically read In a simple setup, the configuration is static and is typically read
from a saved configuration file. All the parameters for the from a saved configuration file. All the parameters for the
association phase are well known after the pre-association phase is association phase are well known after the pre-association phase is
complete. A protocol such as DHCP may be used to retrieve the complete. A protocol such as DHCP may be used to retrieve the
configuration parameters instead of reading them from a static configuration parameters instead of reading them from a static
configuration file. Note, this will still be considered static pre- configuration file. Note, this will still be considered static pre-
association. Dynamic configuration may also happen using the Fc, Ff association. Dynamic configuration may also happen using the Fc, Ff,
and Fl reference points (refer to [RFC3746]). Vendors may use their and Fl reference points (refer to [RFC3746]). Vendors may use their
own proprietary service discovery protocol to pass the parameters. own proprietary service discovery protocol to pass the parameters.
Essentially, only guidelines are provided here and the details are Essentially, only guidelines are provided here and the details are
left to the implementation. left to the implementation.
The following are scenarios reproduced from the Framework Document to The following are scenarios reproduced from the framework document to
show a pre-association example. show a pre-association example.
<----Ff ref pt---> <--Fc ref pt-------> <----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) (security exchange) (security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication 1|<------------>| authentication 1|<----------->|authentication
| | | | | | | |
(FE ID, components) (CE ID, components) (FE ID, components) (CE ID, components)
2|<-------------| request 2|<------------|request 2|<-------------| request 2|<------------|request
| | | | | | | |
3|------------->| response 3|------------>|response 3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID) (corresponding CE ID) (corresponding FE ID)
| | | | | | | |
| | | | | | | |
Figure 5: Examples of a message exchange over the Ff and Fc reference Figure 5: Examples of a Message Exchange over the Ff and Fc
points Reference Points
<-----------Fl ref pt--------------> | <-----------Fl ref pt--------------> |
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) | | (security exchange) | |
1|<------------------------------>| | 1|<------------------------------>| |
| | | | | | | |
(a list of CEs and their components) | (a list of CEs and their components) |
2|<-------------------------------| | 2|<-------------------------------| |
| | | | | | | |
(a list of FEs and their components) | (a list of FEs and their components) |
3|------------------------------->| | 3|------------------------------->| |
| | | | | | | |
| | | | | | | |
Figure 6: An example of a message exchange over the Fl reference Figure 6: Example of a Message Exchange over the Fl Reference Point
point
Before the transition to the association phase, the FEM will have Before the transition to the association phase, the FEM will have
established contact with a CEM component. Initialization of the established contact with a CEM component. Initialization of the
ForCES interface will have completed, and authentication as well as ForCES interface will have completed, and authentication as well as
capability discovery may be complete. Both the FE and CE would have capability discovery may be complete. Both the FE and CE would have
the necessary information for connecting to each other for the necessary information for connecting to each other for
configuration, accounting, identification, and authentication configuration, accounting, identification, and authentication
purposes. To summarize, at the completion of this stage both sides purposes. To summarize, at the completion of this stage both sides
have all the necessary protocol parameters such as timers, etc. The have all the necessary protocol parameters such as timers, etc. The
Fl reference point may continue to operate during the association Fl reference point may continue to operate during the association
phase and may be used to force a disassociation of an FE or CE. The phase and may be used to force a disassociation of an FE or CE. The
specific interactions of the CEM and the FEM that are part of the specific interactions of the CEM and the FEM that are part of the
pre-association phase are out of scope; for this reason these details pre-association phase are out of scope; for this reason, these
are not discussed any further in this specification. The reader is details are not discussed any further in this specification. The
referred to the framework document [RFC3746] for a slightly more reader is referred to the framework document [RFC3746] for a slightly
detailed discussion. more detailed discussion.
4.2.2. Post-association 4.2.2. Post-association
In this phase, the FE and CE components communicate with each other In this phase, the FE and CE components communicate with each other
using the ForCES protocol (PL over TML) as defined in this document. using the ForCES protocol (PL over TML) as defined in this document.
There are three sub-phases: There are three sub-phases:
o Association Setup Stage o Association Setup Stage
o Established Stage o Established Stage
skipping to change at page 19, line 33 skipping to change at page 18, line 48
also send asynchronous event notifications to the CE or synchronous also send asynchronous event notifications to the CE or synchronous
heartbeat notifications if programmed to do so. This stage continues heartbeat notifications if programmed to do so. This stage continues
until a termination occurs, either due to loss of connectivity or due until a termination occurs, either due to loss of connectivity or due
to a termination initiated by either the CE or the FE. to a termination initiated by either the CE or the FE.
Refer to the section on protocol scenarios, Section 4.4, for more Refer to the section on protocol scenarios, Section 4.4, for more
details. details.
4.2.2.3. Association Lost Stage 4.2.2.3. Association Lost Stage
In this state, both or either the CE or FE declare the other side is In this stage, both or either the CE or FE declare the other side is
no longer associated. The disconnection could be initiated by either no longer associated. The disconnection could be initiated by either
party for administrative purposes but may also be driven by party for administrative purposes but may also be driven by
operational reasons such as loss of connectivity. operational reasons such as loss of connectivity.
A core LFB known as FE Protocol Object (FEPO) is defined (refer to A core LFB known as the FE Protocol Object (FEPO) is defined (refer
Appendix B and Section 7.3.1). FEPO defines various timers which can to Appendix B and Section 7.3.1). FEPO defines various timers that
be used in conjunction with traffic sensitive heartbeat mechanism can be used in conjunction with a traffic-sensitive heartbeat
(Section 4.3.3) to detect loss of connectivity. mechanism (Section 4.3.3) to detect loss of connectivity.
The loss of connectivity between TMLs does not indicate a loss of The loss of connectivity between TMLs does not indicate a loss of
association between respective PL layers. If the TML cannot repair association between respective PL layers. If the TML cannot repair
the transport loss before the programmed FEPO timer thresholds the transport loss before the programmed FEPO timer thresholds
associated with the FE is exceeded, then the association between the associated with the FE is exceeded, then the association between the
respective PL layers will be lost. respective PL layers will be lost.
FEPO defines several policies that can be programmed to define FEPO defines several policies that can be programmed to define
behavior upon a detected loss of association. The FEPO's programmed behavior upon a detected loss of association. The FEPO's programmed
CE failover policy (refer to Section 8, Section 7.3.1, Section 4.3.3 CE failover policy (refer to Sections 8, 7.3.1, 4.3.3, and B) defines
and Appendix B) defines what takes place upon loss of association. what takes place upon loss of association.
For this version of the protocol (as defined in this document), the For this version of the protocol (as defined in this document), the
FE, upon re-association, MUST discard any state it has as invalid and FE, upon re-association, MUST discard any state it has as invalid and
retrieve new state. This approach is motivated by a desire for retrieve new state. This approach is motivated by a desire for
simplicity (as opposed to efficiency). simplicity (as opposed to efficiency).
4.3. Protocol Mechanisms 4.3. Protocol Mechanisms
Various semantics are exposed to the protocol users via the PL header Various semantics are exposed to the protocol users via the PL header
including: transaction capabilities, atomicity of transactions, two including transaction capabilities, atomicity of transactions, two-
phase commits, batching/parallelization, high availability and phase commits, batching/parallelization, high availability, and
failover as well as command pipelines. failover as well as command pipelines.
The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP The EM (Execution Mode) flag, AT (Atomic Transaction) flag, and TP
(Transaction Phase) flag as defined in the Common Header (Transaction Phase) flag as defined in the common header
(Section 6.1) are relevant to these mechanisms. (Section 6.1) are relevant to these mechanisms.
4.3.1. Transactions, Atomicity, Execution and Responses 4.3.1. Transactions, Atomicity, Execution, and Responses
In the master-slave relationship the CE instructs one or more FEs on In the master-slave relationship, the CE instructs one or more FEs on
how to execute operations and how to report the results. how to execute operations and how to report the results.
This section details the different modes of execution that a CE can This section details the different modes of execution that a CE can
order the FE(s) to perform, as defined in Section 4.3.1.1. It also order the FE(s) to perform, as defined in Section 4.3.1.1. It also
describes the different modes a CE can ask the FE(s) to use for describes the different modes a CE can ask the FE(s) to use for
formatting the responses after processing the operations as formatting the responses after processing the operations as
requested. These modes relate to the transactional two phase requested. These modes relate to the transactional two-phase commit
commitment operations. operations.
4.3.1.1. Execution 4.3.1.1. Execution
There are 3 execution modes that can be requested for a batch of There are 3 execution modes that can be requested for a batch of
operations spanning one or more LFB selectors (refer to operations spanning one or more LFB selectors (refer to
Section 7.1.5) in one protocol message. The EM flag defined in the Section 7.1.5) in one protocol message. The EM flag defined in the
Common Header Section 6.1 selects the execution mode for a protocol common header (Section 6.1) selects the execution mode for a protocol
message, as below: message, as below:
a. execute-all-or-none a. execute-all-or-none
b. continue-execute-on-failure b. continue-execute-on-failure
c. execute-until-failure c. execute-until-failure
4.3.1.1.1. execute-all-or-none 4.3.1.1.1. execute-all-or-none
When set to this mode of execution, independent operations in a When set to this mode of execution, independent operations in a
message MAY be targeted at one or more LFB selectors within an FE. message MAY be targeted at one or more LFB selectors within an FE.
All these operations are executed serially and the FE MUST have no All these operations are executed serially, and the FE MUST have no
execution failure for any of the operations. If any operation fails execution failure for any of the operations. If any operation fails
to execute, then all the previous ones that have been executed prior to execute, then all the previous ones that have been executed prior
to the failure will need to be undone. I.e., there is rollback for to the failure will need to be undone. That is, there is rollback
this mode of operation. for this mode of operation.
Refer to Section 4.3.1.2.2 for how this mode is used in cases of Refer to Section 4.3.1.2.2 for how this mode is used in cases of
transactions. In such a case, no operation is executed unless a transactions. In such a case, no operation is executed unless a
commit is issued by the CE. commit is issued by the CE.
Care should be taken on how this mode is used because a mis- Care should be taken on how this mode is used because a mis-
configuration could result in traffic losses. To add certainty to configuration could result in traffic losses. To add certainty to
the success of an operation, one should use this mode in a the success of an operation, one should use this mode in a
transactional operation as described in Section 4.3.1.2.2 transactional operation as described in Section 4.3.1.2.2
4.3.1.1.2. continue-execute-on-failure 4.3.1.1.2. continue-execute-on-failure
If several independent operations are targeted at one or more LFB If several independent operations are targeted at one or more LFB
selectors, execution continues for all operations at the FE even if selectors, execution continues for all operations at the FE even if
one or more operations fail. one or more operations fail.
4.3.1.1.3. execute-until-failure 4.3.1.1.3. execute-until-failure
In this mode all operations are executed on the FE sequentially until In this mode, all operations are executed on the FE sequentially
the first failure. The rest of the operations are not executed but until the first failure. The rest of the operations are not executed
operations already completed are not undone. I.e., there is no but operations already completed are not undone. That is, there is
rollback in this mode of operation. no rollback in this mode of operation.
4.3.1.2. Transaction and Atomicity 4.3.1.2. Transaction and Atomicity
4.3.1.2.1. Transaction Definition 4.3.1.2.1. Transaction Definition
A transaction is defined as a collection of one or more ForCES A transaction is defined as a collection of one or more ForCES
operations within one or more PL messages that MUST meet the ACIDity operations within one or more PL messages that MUST meet the ACIDity
properties [ACID], defined as: properties [ACID], defined as:
Atomicity: In a transaction involving two or more discrete pieces Atomicity: In a transaction involving two or more discrete pieces
of information, either all of the pieces are committed of information, either all of the pieces are committed
or none are. or none are.
Consistency: A transaction either creates a new and valid state of Consistency: A transaction either creates a new and valid state of
data, or, if any failure occurs, returns all data to the data or, if any failure occurs, returns all data to the
state it was in before the transaction was started. state it was in before the transaction was started.
Isolation: A transaction in process and not yet committed MUST Isolation: A transaction in process and not yet committed MUST
remain isolated from any other transaction. remain isolated from any other transaction.
Durability: Committed data is saved by the system such that, even in Durability: Committed data is saved by the system such that, even in
the event of a failure and a system restart, the data is the event of a failure and a system restart, the data is
available in its correct state. available in its correct state.
There are cases where the CE knows exact memory and implementation There are cases where the CE knows exact memory and implementation
skipping to change at page 22, line 28 skipping to change at page 21, line 44
As defined above, a transaction is always atomic and MAY be As defined above, a transaction is always atomic and MAY be
a. Within an FE alone a. Within an FE alone
Example: updating multiple tables that are dependent on each Example: updating multiple tables that are dependent on each
other. If updating one fails, then any that were already updated other. If updating one fails, then any that were already updated
MUST be undone. MUST be undone.
b. Distributed across the NE b. Distributed across the NE
Example: updating table(s) that are inter-dependent across Example: updating table(s) that are inter-dependent across
several FEs (such as L3 forwarding related tables). several FEs (such as L3 forwarding-related tables).
4.3.1.2.2. Transaction Protocol 4.3.1.2.2. Transaction Protocol
By use of the execute mode, as defined in Section 4.3.1.1, the By use of the execution mode, as defined in Section 4.3.1.1, the
protocol has provided a mechanism for transactional operations within protocol has provided a mechanism for transactional operations within
one stand-alone message. The 'execute-all-or-none' mode can meet the one stand-alone message. The 'execute-all-or-none' mode can meet the
ACID requirements. ACID requirements.
For transactional operations of multiple messages within one FE or For transactional operations of multiple messages within one FE or
across FEs, a classical transactional protocol known as Two Phase across FEs, a classical transactional protocol known as two-phase
Commit (2PC) [2PCREF] is supported by the protocol to achieve the commit (2PC) [2PCREF] is supported by the protocol to achieve the
transactional operations utilizing Config messages (Section 7.6.1). transactional operations utilizing Config messages (Section 7.6.1).
The COMMIT and TRCOMP operations in conjunction with the AT and the The COMMIT and TRCOMP operations in conjunction with the AT and the
TP flags in Common Header (Section 6.1) are provided for 2PC-based TP flags in the common header (Section 6.1) are provided for 2PC-
transactional operations spanning multiple messages. based transactional operations spanning multiple messages.
The AT flag, when set, indicates this message belongs to an Atomic
Transaction. All messages for a transaction operation MUST have the
AT flag set. If not set, it means the message is a stand-alone
message and does not participate in any transaction operation that
spans multiple messages.
The TP flag indicates the Transaction Phase this message belongs to. The AT flag, when set, indicates that this message belongs to an
Atomic Transaction. All messages for a transaction operation MUST
have the AT flag set. If not set, it means that the message is a
stand-alone message and does not participate in any transaction
operation that spans multiple messages.
There are four (4) possible phases for an transactional operation The TP flag indicates the Transaction Phase to which this message
belongs. There are 4 possible phases for a transactional operation
known as: known as:
SOT (Start of Transaction) SOT (Start of Transaction)
MOT (Middle of Transaction) MOT (Middle of Transaction)
EOT (End of Transaction) EOT (End of Transaction)
ABT (Abort) ABT (Abort)
The COMMIT operation is used by the CE to signal to the FE(s) to The COMMIT operation is used by the CE to signal to the FE(s) to
commit a transaction. When used with an ABT TP flag, the COMMIT commit a transaction. When used with an ABT TP flag, the COMMIT
operation signals the FE(s) to rollback (i.e un-COMMIT) a previously operation signals the FE(s) to roll back (i.e., un-COMMIT) a
committed transaction. previously committed transaction.
The TRCOMP operation is a small addition to the classical 2PC The TRCOMP operation is a small addition to the classical 2PC
approach. TRCOMP is sent by the CE to signal the FE(s) that the approach. TRCOMP is sent by the CE to signal to the FE(s) that the
transaction they have COMMITed is now over. This allows the FE(s) an transaction they have COMMITed is now over. This allows the FE(s) an
opportunity to clear state they may have kept around to perform a opportunity to clear state they may have kept around to perform a
rollback (if it became necessary). roll back (if it became necessary).
A transaction operation is started with a message in which the TP A transaction operation is started with a message in which the TP
flag is set to Start of Transaction (SOT). Multi-part messages, flag is set to Start of Transaction (SOT). Multi-part messages,
after the first one, are indicated by the Middle of Transaction flag after the first one, are indicated by the Middle of Transaction (MOT)
(MOT). All messages from the CE MUST set the AlwaysACK flag flag. All messages from the CE MUST set the AlwaysACK flag
(Section 6) to solicit responses from the FE(s). (Section 6) to solicit responses from the FE(s).
Before the CE issues a commit (described further below) the FE MUST Before the CE issues a commit (described further below), the FE MUST
only validate that the operation can be executed but not execute it. only validate that the operation can be executed but not execute it.
Any failure notified by an FE causes the CE to abort the Any failure notified by an FE causes the CE to abort the
transaction on all FEs involved in the transaction. This is transaction on all FEs involved in the transaction. This is
achieved by sending a Config message with an ABT flag and a COMMIT achieved by sending a Config message with an ABT flag and a COMMIT
operation. operation.
If there are no failures by any participating FE, the transaction If there are no failures by any participating FE, the transaction
commitment phase is signaled from the CE to the FE by an End of commitment phase is signaled from the CE to the FE by an End of
Transaction (EOT) configuration message with a COMMIT operation. Transaction (EOT) configuration message with a COMMIT operation.
skipping to change at page 24, line 8 skipping to change at page 23, line 24
The FE MUST respond to the CE's EOT message. There are two possible The FE MUST respond to the CE's EOT message. There are two possible
failure scenarios in which the CE MUST abort the transaction (as failure scenarios in which the CE MUST abort the transaction (as
described above): described above):
a. If any participating FE responds with a failure message in a. If any participating FE responds with a failure message in
relation to the transaction. relation to the transaction.
b. If no response is received from a participating FE within a b. If no response is received from a participating FE within a
specified timeout. specified timeout.
If all participating FE(s) respond with a success indicator within If all participating FEs respond with a success indicator within the
the expected time, then the CE MUST issue a TRCOMP operation to all expected time, then the CE MUST issue a TRCOMP operation to all
participating FEs. An FE MUST NOT respond to a TRCOMP. participating FEs. An FE MUST NOT respond to a TRCOMP.
Note that a transactional operation is generically atomic, therefore Note that a transactional operation is generically atomic; therefore,
it requires that the execute modes of all messages in a transaction it requires that the execution modes of all messages in a transaction
operation should always be kept the same and be set to 'execute-all- operation should always be kept the same and be set to 'execute-all-
or-none'. If the EM flag is set to other execute modes, it will or-none'. If the EM flag is set to other execution modes, it will
result in a transaction failure. result in a transaction failure.
As noted above, a transaction may span multiple messages. It is up As noted above, a transaction may span multiple messages. It is up
to the CE to keep track of the different outstanding messages making to the CE to keep track of the different outstanding messages making
up a transaction. As an example, the correlator field could be used up a transaction. As an example, the correlator field could be used
to mark transactions and a sequence field to label the different to mark transactions and a sequence field to label the different
messages within the same atomic transaction, but this is out of scope messages within the same atomic transaction, but this is out of scope
and up to implementations. and up to implementations.
4.3.1.2.3. Recovery 4.3.1.2.3. Recovery
Any of the participating FEs, or the CE, or the associations between Any of the participating FEs or the CE or the associations between
them, may fail after the EOT response message has been sent by the FE them may fail after the EOT Response message has been sent by the FE
but before the CE has received all the responses, e.g. if the EOT but before the CE has received all the responses, e.g., if the EOT
response never reaches the CE. response never reaches the CE.
In this protocol revision, as indicated in Section 4.2.2.3, an FE In this protocol revision, as indicated in Section 4.2.2.3, an FE
losing an association would be required to get entirely new state losing an association would be required to get entirely new state
from the newly associated CE upon a re-association. Although this from the newly associated CE upon a re-association. Although this
approach is simplistic and provides likeliness of loosing datapath approach is simplistic and provides likeliness of losing data path
traffic, it is a design choice to avoid the additional complexity of traffic, it is a design choice to avoid the additional complexity of
managing graceful restarts. The HA mechanisms (Section 8) are managing graceful restarts. The HA mechanisms (Section 8) are
provided to allow for a continuous operation in case of FE failures. provided to allow for a continuous operation in case of FE failures.
Flexibility is provided on how to react when an FE looses Flexibility is provided on how to react when an FE loses association.
association. This is dictated by the CE Failover policy (refer to This is dictated by the CE failover policy (refer to Section 8 and
Section 8 and Section 7.3). Section 7.3).
4.3.1.2.4. Transaction Messaging Example 4.3.1.2.4. Transaction Messaging Example
This section illustrates an example of how a successful two phase This section illustrates an example of how a successful two-phase
commit between a CE and an FE would look like in the simple case. commit between a CE and an FE would look in the simple case.
FE PL CE PL FE PL CE PL
| | | |
| (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| (2) ACKnowledge | | (2) ACKnowledge |
|----------------------------------------------------->| |----------------------------------------------------->|
| | | |
skipping to change at page 25, line 39 skipping to change at page 24, line 51
| | | |
| (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE| | (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE|
|----------------------------------------------------->| |----------------------------------------------------->|
| | | |
| (N+2) Config, OP=TRCOMP | | (N+2) Config, OP=TRCOMP |
|<-----------------------------------------------------| |<-----------------------------------------------------|
Figure 7: Example of a two phase commit Figure 7: Example of a Two-Phase Commit
For the scenario illustrated above: For the scenario illustrated above:
o In step #1, the CE issues a Config message with an operation of o In step 1, the CE issues a Config message with an operation of
choice like a DEL or SET. The transactional flag are set to choice like a DEL or SET. The transaction flags are set to
indicate a Start of Transaction (SOT), Atomic Transaction (AT), indicate a Start of Transaction (SOT), Atomic Transaction (AT),
execute-all-or-none. and execute-all-or-none.
o The FE validates that it can execute the request successfully and o The FE validates that it can execute the request successfully and
then issues an acknowledgment back to the the CE in step #2. then issues an acknowledgment back to the CE in step 2.
o In step #3, the same sort of construct as in step #1 is repeated o In step 3, the same sort of construct as in step 1 is repeated by
by the CE with the transaction flag changed to Middle of the CE with the transaction flag changed to Middle of Transaction
Transaction(MOT). (MOT).
o The FE validates that it can execute the request successfully and o The FE validates that it can execute the request successfully and
then issues an acknowledgment back to the the CE in step #4. then issues an acknowledgment back to the CE in step 4.
o The CE-FE exchange continues in the same manner until all the o The CE-FE exchange continues in the same manner until all the
operations and their parameters are transferred to the FE. This operations and their parameters are transferred to the FE. This
happens in step #(N-1). happens in step (N-1).
o In step #N, the CE issues a commit. A commit is a config message o In step N, the CE issues a commit. A commit is a Config message
with an operation of type COMMIT. The transactional flags are set with an operation of type COMMIT. The transaction flag is set to
to End of Transaction (EOT). Essentially, this is an "empty" End of Transaction (EOT). Essentially, this is an "empty" message
message asking the FE to execute all the operations it has asking the FE to execute all the operations it has gathered since
gathered since the beginning of the transaction (message #1). the beginning of the transaction (message #1).
o The FE at this point executes the full transaction. It then o The FE at this point executes the full transaction. It then
issues an acknowledgment back to the the CE in step #(N+1) which issues an acknowledgment back to the CE in step (N+1) that
contains a COMMIT-RESPONSE. contains a COMMIT-RESPONSE.
o The CE in this case has the simple task of issuing a TRCOMP o The CE in this case has the simple task of issuing a TRCOMP
operation the the FE in step #(N+2) operation to the FE in step (N+2).
4.3.2. Scalability 4.3.2. Scalability
It is desirable that the PL not become the bottleneck when larger It is desirable that the PL not become the bottleneck when larger
bandwidth pipes become available. To pick a hypothetical example in bandwidth pipes become available. To pick a hypothetical example in
today's terms, if a 100Gbps pipe is available and there is sufficient today's terms, if a 100-Gbps pipe is available and there is
work then the PL should be able to take advantage of this and use all sufficient work, then the PL should be able to take advantage of this
of the 100Gbps pipe. Two mechanisms have been provided to achieve and use all of the 100-Gbps pipe. Two mechanisms have been provided
this. The first one is batching and the second one is a command to achieve this. The first one is batching and the second one is a
pipeline. command pipeline.
Batching is the ability to send multiple commands (such as Config) in Batching is the ability to send multiple commands (such as Config) in
one Protocol Data Unit (PDU). The size of the batch will be affected one Protocol Data Unit (PDU). The size of the batch will be affected
by, amongst other things, the path MTU. The commands may be part of by, among other things, the path MTU. The commands may be part of
the same transaction or may be part of unrelated transactions that the same transaction or may be part of unrelated transactions that
are independent of each other. are independent of each other.
Command pipelining allows for pipelining of independent transactions Command pipelining allows for pipelining of independent transactions
which do not affect each other. Each independent transaction could that do not affect each other. Each independent transaction could
consist of one or more batches. consist of one or more batches.
4.3.2.1. Batching 4.3.2.1. Batching
There are several batching levels at different protocol hierarchies. There are several batching levels at different protocol hierarchies.
o multiple PL PDUs can be aggregated under one TML message o Multiple PL PDUs can be aggregated under one TML message.
o multiple LFB classes and instances (as indicated in the LFB
selector) can be addressed within one PL PDU o Multiple LFB classes and instances (as indicated in the LFB
selector) can be addressed within one PL PDU.
o Multiple operations can be addressed to a single LFB class and o Multiple operations can be addressed to a single LFB class and
instance instance.
4.3.2.2. Command Pipelining 4.3.2.2. Command Pipelining
The protocol allows any number of messages to be issued by the CE The protocol allows any number of messages to be issued by the CE
before the corresponding acknowledgments (if requested) have been before the corresponding acknowledgments (if requested) have been
returned by the FE. Hence pipelining is inherently supported by the returned by the FE. Hence, pipelining is inherently supported by the
protocol. Matching responses with requests messages can be done protocol. Matching responses with requests messages can be done
using the correlator field in the message header. using the correlator field in the message header.
4.3.3. Heartbeat Mechanism 4.3.3. Heartbeat Mechanism
Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is Heartbeats (HBs) between FEs and CEs are traffic sensitive. An HB is
sent only if no PL traffic is sent between the CE and FE within a sent only if no PL traffic is sent between the CE and FE within a
configured interval. This has the effect of reducing the amount of configured interval. This has the effect of reducing the amount of
HB traffic in the case of busy PL periods. HB traffic in the case of busy PL periods.
An HB can be sourced by either the CE or FE. When sourced by the CE, An HB can be sourced by either the CE or FE. When sourced by the CE,
a response can be requested (similar to the ICMP ping protocol). The a response can be requested (similar to the ICMP ping protocol). The
FE can only generate HBs in the case of being configured to do so by FE can only generate HBs in the case of being configured to do so by
the CE. Refer to Section 7.3.1 and Section 7.10 for details. the CE. Refer to Section 7.3.1 and Section 7.10 for details.
4.3.4. FE Object and FE Protocol LFBs 4.3.4. FE Object and FE Protocol LFBs
All PL messages operate on LFB constructs, as this provides more All PL messages operate on LFB constructs, as this provides more
flexibility for future enhancements. This means that maintenance and flexibility for future enhancements. This means that maintenance and
configurability of FEs, NE, as well as the ForCES protocol itself configurability of FEs, NE, and the ForCES protocol itself MUST be
MUST be expressed in terms of this LFB architecture. For this reason expressed in terms of this LFB architecture. For this reason,
special LFBs are created to accommodate this need. special LFBs are created to accommodate this need.
In addition, this shows how the ForCES protocol itself can be In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc. control functions such as IP forwarding, filtering, etc.
To achieve this, the following specialized LFBs are introduced: To achieve this, the following specialized LFBs are introduced:
o FE Protocol LFB which is used to control the ForCES protocol. o FE Protocol LFB, which is used to control the ForCES protocol.
o FE Object LFB which is used to control attributes relative to the o FE Object LFB, which is used to control components relative to the
FE itself. Such attributes include FEState [FE-MODEL], vendor, FE itself. Such components include FEState [RFC5812], vendor,
etc. etc.
These LFBs are detailed in Section 7.3. These LFBs are detailed in Section 7.3.
4.4. Protocol Scenarios 4.4. Protocol Scenarios
This section provides a very high level description of sample message This section provides a very high level description of sample message
sequences between a CE and FE. For protocol message encoding refer sequences between a CE and an FE. For protocol message encoding
to Section 6.1 and for the semantics of the protocol refer to refer to Section 6.1, and for the semantics of the protocol refer to
Section 4.3. Section 4.3.
4.4.1. Association Setup State 4.4.1. Association Setup State
The associations among CEs and FEs are initiated via Association The associations among CEs and FEs are initiated via the Association
setup message from the FE. If a setup request is granted by the CE, Setup message from the FE. If a Setup Request is granted by the CE,
a successful setup response message is sent to the FE. If CEs and a successful Setup Response message is sent to the FE. If CEs and
FEs are operating in an insecure environment then the security FEs are operating in an insecure environment, then the security
associations have to be established between them before any associations have to be established between them before any
association messages can be exchanged. The TML MUST take care of association messages can be exchanged. The TML MUST take care of
establishing any security associations. establishing any security associations.
This is typically followed by capability query, topology query, etc. This is typically followed by capability query, topology query, etc.
When the FE is ready to start processing the data path, it sets the When the FE is ready to start processing the data path, it sets the
FEO FEState component to OperEnable (Refer to [FE-MODEL] for details) FEO FEState component to OperEnable (refer to [RFC5812] for details)
and reports it to the CE as such when it is first queried. Typically and reports it to the CE as such when it is first queried.
the FE is expected to be ready to process the data path before it Typically, the FE is expected to be ready to process the data path
associates, but there maybe rare cases where it needs time do some before it associates, but there may be rare cases where it needs time
pre-processing - in such a case the FE will start in the OperDisable do some pre-processing -- in such a case, the FE will start in the
state and when it is ready will transition to OperEnable state. An OperDisable state and when it is ready will transition to the
example of an FE starting in the OperDisable then transitioning to OperEnable state. An example of an FE starting in OperDisable then
OperEnable is illustrated in Figure 8. The CE could at any time also transitioning to OperEnable is illustrated in Figure 8. The CE could
disable the FEs datapath operations by setting the FEState to at any time also disable the FE's data path operations by setting the
AdminDisable. The FE MUST NOT process packets during this state FEState to AdminDisable. The FE MUST NOT process packets during this
unless the CE sets the state back to OperEnable. These sequences of state unless the CE sets the state back to OperEnable. These
messages are illustrated in Figure 8 below. sequences of messages are illustrated in Figure 8 below.
FE PL CE PL FE PL CE PL
| | | |
| Asso Setup Req | | Asso Setup Req |
|---------------------->| |---------------------->|
| | | |
| Asso Setup Resp | | Asso Setup Resp |
|<----------------------| |<----------------------|
| | | |
skipping to change at page 29, line 36 skipping to change at page 28, line 41
| FEO OperEnable Event | | FEO OperEnable Event |
|---------------------->| |---------------------->|
| | | |
| Config FEO Adminup | | Config FEO Adminup |
|<----------------------| |<----------------------|
| | | |
| FEO Config-Resp | | FEO Config-Resp |
|---------------------->| |---------------------->|
| | | |
Figure 8: Message exchange between CE and FE to establish an NE Figure 8: Message Exchange between CE and FE to Establish
association an NE Association
On successful completion of this state, the FE joins the NE. On successful completion of this state, the FE joins the NE.
4.4.2. Association Established state or Steady State 4.4.2. Association Established State or Steady State
In this state, the FE is continuously updated or queried. The FE may In this state, the FE is continuously updated or queried. The FE may
also send asynchronous event notifications to the CE, synchronous also send asynchronous event notifications to the CE, synchronous
heartbeat messages, or packet redirect message to the CE. This Heartbeat messages, or Packet Redirect message to the CE. This
continues until a termination (or deactivation) is initiated by continues until a termination (or deactivation) is initiated by
either the CE or FE. Figure 9 below, helps illustrate this state. either the CE or FE. Figure 9 below, helps illustrate this state.
FE PL CE PL FE PL CE PL
| | | |
| Heart Beat | | Heartbeat |
|<---------------------------->| |<---------------------------->|
| | | |
| Heart Beat | | Heartbeat |
|----------------------------->| |----------------------------->|
| | | |
| Config-set LFBy (Event sub.) | | Config-set LFBy (Event sub.) |
|<-----------------------------| |<-----------------------------|
| | | |
| Config Resp LFBy | | Config Resp LFBy |
|----------------------------->| |----------------------------->|
| | | |
| Config-set LFBx Attr | | Config-set LFBx Component |
|<-----------------------------| |<-----------------------------|
| | | |
| Config Resp LFBx | | Config Resp LFBx |
|----------------------------->| |----------------------------->|
| | | |
|Config-Query LFBz (Stats) | |Config-Query LFBz (Stats) |
|<--------------------------- -| |<--------------------------- -|
| | | |
| Query Resp LFBz | | Query Resp LFBz |
|----------------------------->| |----------------------------->|
| | | |
| FE Event Report | | FE Event Report |
|----------------------------->| |----------------------------->|
| | | |
| Config-Del LFBx Attr | | Config-Del LFBx Component |
|<-----------------------------| |<-----------------------------|
| | | |
| Config Resp LFBx | | Config Resp LFBx |
|----------------------------->| |----------------------------->|
| | | |
| Packet Redirect LFBx | | Packet Redirect LFBx |
|----------------------------->| |----------------------------->|
| | | |
| Heart Beat | | Heartbeat |
|<-----------------------------| |<-----------------------------|
. . . .
. . . .
| | | |
Figure 9: Message exchange between CE and FE during steady-state Figure 9: Message Exchange between CE and FE during
communication Steady-State Communication
Note that the sequence of messages shown in the figure serve only as Note that the sequence of messages shown in the figure serve only as
examples and the message exchange sequences could be different from examples and the message exchange sequences could be different from
what is shown in the figure. Also, note that the protocol scenarios what is shown in the figure. Also, note that the protocol scenarios
described in this section do not include all the different message described in this section do not include all the different message
exchanges that would take place during failover. That is described exchanges that would take place during failover. That is described
in the HA section (Section 8) . in the HA section (Section 8).
5. TML Requirements 5. TML Requirements
The requirements below are expected to be met by the TML. This text The requirements below are expected to be met by the TML. This text
does not define how such mechanisms are delivered. As an example, does not define how such mechanisms are delivered. As an example,
the mechanisms to meet the requirements could be defined to be the mechanisms to meet the requirements could be defined to be
delivered via hardware or between 2 or more TML software processes on delivered via hardware or between 2 or more TML software processes on
different CEs or FEs in protocol level schemes. different CEs or FEs in protocol-level schemes.
Each TML MUST describe how it contributes to achieving the listed Each TML MUST describe how it contributes to achieving the listed
ForCES requirements. If for any reason a TML does not provide a ForCES requirements. If for any reason a TML does not provide a
service listed below a justification needs to be provided. service listed below, a justification needs to be provided.
Implementations that support the ForCES Protocol Specification MUST Implementations that support the ForCES protocol specification MUST
IMPLEMENT [SCTP-TML]. Note that additional TMLs might be specified implement [RFC5811]. Note that additional TMLs might be specified in
in the future, and if a new TML defined in the future that meets the the future, and if a new TML defined in the future that meets the
requirements listed here proves to be better, then the MUST IMPLEMENT requirements listed here proves to be better, then the "MUST
TML may redefined. implement TML" may be redefined.
1. Reliability 1. Reliability
Various ForCES messages will require varying degrees of reliable Various ForCES messages will require varying degrees of reliable
delivery via the TML. It is the TML's responsibility to provide delivery via the TML. It is the TML's responsibility to provide
these shades of reliability and describe how the different ForCES these shades of reliability and describe how the different ForCES
messages map to reliability. messages map to reliability.
The most common level of reliability is what we refer to as The most common level of reliability is what we refer to as
strict or robust reliability in which we mean: no losses, strict or robust reliability in which we mean no losses,
corruption, or re-ordering of information being transported while corruption, or re-ordering of information being transported while
ensuring message delivery in a timely fashion. ensuring message delivery in a timely fashion.
Payloads such as configuration from a CE and its response from an Payloads such as configuration from a CE and its response from an
FE are mission critical and must be delivered in a robust FE are mission critical and must be delivered in a robust
reliable fashion. Thus, for information of this sort, the TML reliable fashion. Thus, for information of this sort, the TML
MUST either provide built-in protocol mechanisms or use a MUST either provide built-in protocol mechanisms or use a
reliable transport protocol for achieving robust/strict reliable transport protocol for achieving robust/strict
reliability. reliability.
Some information or payloads, such as redirected packets or Some information or payloads, such as redirected packets or
packet sampling, may not require robust reliability (can tolerate packet sampling, may not require robust reliability (can tolerate
some degree of losses). For information of this sort, the TML some degree of losses). For information of this sort, the TML
could define to use a mechanism that is not strictly reliable could define to use a mechanism that is not strictly reliable
(while conforming to other TML requirements such as congestion (while conforming to other TML requirements such as congestion
control). control).
Some information or payloads, such as heartbeat packets that may Some information or payloads, such as heartbeat packets, may
prefer timeliness over reliable delivery. For information of prefer timeliness over reliable delivery. For information of
this sort, the TML could define to use a mechanism that is not this sort, the TML could define to use a mechanism that is not
strictly reliable (while conforming to other TML requirements strictly reliable (while conforming to other TML requirements
such as congestion control). such as congestion control).
2. Security 2. Security
TML provides security services to the ForCES PL. Because a TML provides security services to the ForCES PL. Because a
ForCES PL is used to operate an NE, attacks designed to confuse, ForCES PL is used to operate an NE, attacks designed to confuse,
disable, or take information from a ForCES-based NE may be seen disable, or take information from a ForCES-based NE may be seen
as a prime objective during a network attack. as a prime objective during a network attack.
An attacker in a position to inject false messages into a PL An attacker in a position to inject false messages into a PL
stream can either affect the FE's treatment of the data path stream can affect either the FE's treatment of the data path (for
(example by falsifying control data reported as coming from the example, by falsifying control data reported as coming from the
CE), or the CE itself (by modifying events or responses reported CE) or the CE itself (by modifying events or responses reported
as coming from the FE); for this reason, CE and FE node as coming from the FE). For this reason, CE and FE node
authentication and TML Message authentication is important. authentication and TML message authentication are important.
The PL messages may also contain information of value to an The PL messages may also contain information of value to an
attacker, including information about the configuration of the attacker, including information about the configuration of the
network, encryption keys and other sensitive control data, so network, encryption keys, and other sensitive control data, so
care must be taken to confine their visibility to authorized user care must be taken to confine their visibility to authorized
users.
* The TML MUST provide a mechanism to authenticate ForCES CEs * The TML MUST provide a mechanism to authenticate ForCES CEs
and FEs in order to prevent the participation of unauthorized and FEs, in order to prevent the participation of unauthorized
CEs and unauthorized FEs in the control and data path CEs and unauthorized FEs in the control and data path
processing of a ForCES NE. processing of a ForCES NE.
* The TML SHOULD provide a mechanism to ensure message * The TML SHOULD provide a mechanism to ensure message
authentication of PL data transferred from the CE to FE (and authentication of PL data transferred from the CE to FE (and
vice-versa) in order to prevent the injection of incorrect vice versa), in order to prevent the injection of incorrect
data into PL messages. data into PL messages.
* The TML SHOULD provide a mechanism to ensure the * The TML SHOULD provide a mechanism to ensure the
confidentiality of data transferred from the ForCES PL, in confidentiality of data transferred from the ForCES PL, in
order to prevent disclosure of PL level information order to prevent disclosure of PL-level information
transported via the TML. transported via the TML.
The TML SHOULD provide these services by employing TLS or IPSEC. The TML SHOULD provide these services by employing TLS or IPsec.
3. Congestion control 3. Congestion control
The transport congestion control scheme used by the TML needs to The transport congestion control scheme used by the TML needs to
be defined. The congestion control mechanism defined by the TML be defined. The congestion control mechanism defined by the TML
MUST prevent transport congestive collapse [RFC2914] on either MUST prevent transport congestive collapse [RFC2914] on either
the FE or CE side. the FE or CE side.
4. Uni/multi/broadcast addressing/delivery, if any 4. Uni/multi/broadcast addressing/delivery, if any
If there is any mapping between PL and TML level uni/multi/
broadcast addressing it needs to be defined. If there is any mapping between PL- and TML-level uni/multi/
broadcast addressing, it needs to be defined.
5. HA decisions 5. HA decisions
It is expected that availability of transport links is the TML's It is expected that availability of transport links is the TML's
responsibility. However, based upon its configuration, the PL responsibility. However, based upon its configuration, the PL
may wish to participate in link failover schemes and therefore may wish to participate in link failover schemes and therefore
the TML MUST support this capability. the TML MUST support this capability.
Please refer to Section 8 for details. Please refer to Section 8 for details.
6. Encapsulations used 6. Encapsulations used
Different types of TMLs will encapsulate the PL messages on Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the different types of headers. The TML needs to specify the
encapsulation used. encapsulation used.
7. Prioritization 7. Prioritization
It is expected that the TML will be able to handle up to 8 It is expected that the TML will be able to handle up to 8
priority levels needed by the PL and will provide preferential priority levels needed by the PL and will provide preferential
treatment. treatment.
While the TML needs to define how this is achieved, it should be While the TML needs to define how this is achieved, it should be
noted that the requirement for supporting up to 8 priority levels noted that the requirement for supporting up to 8 priority levels
does not mean that the underlying TML MUST be capable of does not mean that the underlying TML MUST be capable of
providing up to 8 actual priority levels. In the event that the providing up to 8 actual priority levels. In the event that the
underlying TML layer does not have support for 8 priority levels, underlying TML layer does not have support for 8 priority levels,
the supported priority levels should be divided between the the supported priority levels should be divided between the
skipping to change at page 34, line 29 skipping to change at page 33, line 47
priority levels needed by the PL and will provide preferential priority levels needed by the PL and will provide preferential
treatment. treatment.
While the TML needs to define how this is achieved, it should be While the TML needs to define how this is achieved, it should be
noted that the requirement for supporting up to 8 priority levels noted that the requirement for supporting up to 8 priority levels
does not mean that the underlying TML MUST be capable of does not mean that the underlying TML MUST be capable of
providing up to 8 actual priority levels. In the event that the providing up to 8 actual priority levels. In the event that the
underlying TML layer does not have support for 8 priority levels, underlying TML layer does not have support for 8 priority levels,
the supported priority levels should be divided between the the supported priority levels should be divided between the
available TML priority levels. For example, if the TML only available TML priority levels. For example, if the TML only
supports 2 priority levels, the 0-3 could go in one TML priority supports 2 priority levels, 0-3 could go in one TML priority
level, while 4-7 could go in the other. level, while 4-7 could go in the other.
The TML MUST NOT reorder config packets with the same priority. The TML MUST NOT re-order config packets with the same priority.
8. Node Overload Prevention 8. Node Overload Prevention
The TML MUST define mechanisms it uses to help prevent node The TML MUST define mechanisms it uses to help prevent node
overload. overload.
Overload results in starvation of node compute cycles and/or Overload results in starvation of node compute cycles and/or
bandwidth resources which reduces the operational capacity of a bandwidth resources, which reduces the operational capacity of a
ForCES NE. NE node overload could be deliberately instigated by ForCES NE. NE node overload could be deliberately instigated by
a hostile node to attack a ForCES NE and create a denial of a hostile node to attack a ForCES NE and create a denial of
service. It could also be created by a variety of other reasons service (DoS). It could also be created by a variety of other
such as large control protocol updates (eg BGP flaps) which reasons such as large control protocol updates (e.g., BGP flaps),
consequently cause a high frequency of CE to FE table updates, HA which consequently cause a high frequency of CE to FE table
failovers or component failures which migrate an FE or CE load updates, HA failovers, or component failures, which migrate an FE
overwhelming the new CE or FE, etc. Although the environment or CE load overwhelming the new CE or FE, etc. Although the
under which SIP and ForCES operate are different, [RFC5390] environments under which SIP and ForCES operate are different,
provides a good guide to generic node requirements one needs to [RFC5390] provides a good guide to generic node requirements one
guard for. needs to guard for.
A ForCES node CPU may be overwhelmed because the incoming packet A ForCES node CPU may be overwhelmed because the incoming packet
rate is higher than it can keep up with - in such a case a nodes rate is higher than it can keep up with -- in such a case, a
transport queues grow and transport congestion subsequently node's transport queues grow and transport congestion
follows. A ForCES node CPU may also be adversely overloaded with subsequently follows. A ForCES node CPU may also be adversely
very few packets i.e no transport congestion at all (eg a in a overloaded with very few packets, i.e., no transport congestion
DOS attack against a table hashing algorithmn which overflows the at all (e.g., a in a DoS attack against a table hashing algorithm
table and/or keeps the CPU busy so it does not process other that overflows the table and/or keeps the CPU busy so it does not
tasks) The TML node-overload solution specified MUST address both process other tasks). The TML node overload solution specified
types of node overload scenarios. MUST address both types of node overload scenarios.
5.1. TML Parameterization 5.1. TML Parameterization
It is expected that it should be possible to use a configuration It is expected that it should be possible to use a configuration
reference point, such as the FEM or the CEM, to configure the TML. reference point, such as the FEM or the CEM, to configure the TML.
Some of the configured parameters may include: Some of the configured parameters may include:
o PL ID o PL ID
o Connection Type and associated data. For example if a TML uses o Connection Type and associated data. For example, if a TML uses
IP/TCP/UDP, then parameters such as TCP and UDP port and IP IP/TCP/UDP, then parameters such as TCP and UDP port and IP
addresses need to be configured. addresses need to be configured.
o Number of transport connections o Number of transport connections
o Connection capability, such as bandwidth, etc. o Connection capability, such as bandwidth, etc.
o Allowed/supported connection QoS policy (or congestion control o Allowed/supported connection QoS policy (or congestion control
policy) policy)
6. Message Encapsulation 6. Message Encapsulation
All PL PDUs start with a common header [Section 6.1] followed by a All PL PDUs start with a common header Section 6.1 followed by one or
one or more TLVs [Section 6.2] which may nest other TLVs more TLVs Section 6.2, which may nest other TLVs Section 6.2.1. All
[Section 6.2.1]. All fields are in network byte order. fields are in network byte order.
6.1. Common Header 6.1. Common Header
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length | |version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 31 skipping to change at page 35, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[63:32] | | Correlator[63:32] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[31:0] | | Correlator[31:0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Common Header Figure 10: Common Header
The message is 32 bit aligned. The message is 32-bit aligned.
Version (4 bit): Version (4 bits):
Version number. Current version is 1. Version number. Current version is 1.
rsvd (4 bit): rsvd (4 bits):
Unused at this point. A receiver should not interpret this Unused at this point. A receiver should not interpret this field.
field. Senders MUST set it to zero and receivers MUST ignore Senders MUST set it to zero and receivers MUST ignore this field.
this field.
Message Type (8 bits): Message Type (8 bits):
Commands are defined in Section 7. Commands are defined in Section 7.
Length (16 bits): Length (16 bits):
length of header + the rest of the message in DWORDS (4 byte length of header + the rest of the message in DWORDS (4-byte
increments). increments).
Source ID (32 bit): Source ID (32 bits):
Dest ID (32 bit): Dest ID (32 bits):
* Each of the source and destination IDs are 32 bit IDs which * Each of the source and destination IDs are 32-bit IDs that are
are unique NE-wide and which identify the termination points unique NE-wide and that identify the termination points of a
of a ForCES PL message. ForCES PL message.
* IDs allow multi/broad/unicast addressing with the following * IDs allow multi/broad/unicast addressing with the following
approach: approach:
a. A split address space is used to distinguish FEs from a. A split address space is used to distinguish FEs from CEs.
CEs. Even though in a large NE there are typically two Even though in a large NE there are typically two or more
or more orders of magnitude more FEs than CEs, the orders of magnitude of more FEs than CEs, the address
address space is split uniformly for simplicity. space is split uniformly for simplicity.
b. The address space allows up to 2^30 (over a billion) CEs b. The address space allows up to 2^30 (over a billion) CEs
and the same amount of FEs. and the same amount of FEs.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TS | sub-ID | |TS | sub-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ForCES ID Format Figure 11: ForCES ID Format
c. The 2 most significant bits called Type Switch (TS) are c. The 2 most significant bits called Type Switch (TS) are
used to split the ID space as follows: used to split the ID space as follows:
TS Corresponding ID range Assignment TS Corresponding ID range Assignment
-- ---------------------- ---------- -- ---------------------- ----------
0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
0b10 0x80000000 to 0xBFFFFFFF reserved 0b10 0x80000000 to 0xBFFFFFFF reserved
0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16)
0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
0b11 0xFFFFFFFD all CEs broadcast 0b11 0xFFFFFFFD all CEs broadcast
0b11 0xFFFFFFFE all FEs broadcast 0b11 0xFFFFFFFE all FEs broadcast
0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
Figure 12: Type Switch ID Space Figure 12: Type Switch ID Space
* Multicast or broadcast IDs are used to group endpoints (such * Multicast or broadcast IDs are used to group endpoints (such
as CEs and FES). As an example one could group FEs in some as CEs and FEs). As an example, one could group FEs in some
functional group, by assigning a multicast ID. Likewise, functional group, by assigning a multicast ID. Likewise,
subgroups of CEs that act, for instance, in a back-up mode subgroups of CEs that act, for instance, in a back-up mode may
may be assigned a multicast ID to hide them from the FE. be assigned a multicast ID to hide them from the FE.
+ Multicast IDs can be used for both source or destination + Multicast IDs can be used for both source or destination
IDs. IDs.
+ Broadcast IDs can be used only for destination IDs. + Broadcast IDs can be used only for destination IDs.
* This document does not discuss how a particular multicast ID * This document does not discuss how a particular multicast ID
is associated to a given group though it could be done via is associated to a given group though it could be done via
configuration process. The list of IDs an FE owns or is part configuration process. The list of IDs an FE owns or is part
of are listed on the FE Object LFB. of are listed on the FE Object LFB.
Correlator (64 bits) Correlator (64 bits):
This field is set by the CE to correlate ForCES Request Messages
with the corresponding Response messages from the FE.
Essentially it is a cookie. The correlator is handled
transparently by the FE, i.e., for a particular Request message
the FE MUST assign the same correlator value in the corresponding
Response message. In the case where the message from the CE does
not elicit a response, this field may not be useful.
The correlator field could be used in many implementations This field is set by the CE to correlate ForCES Request messages
specific ways by the CE. For example, the CE could split the with the corresponding Response messages from the FE.
correlator into a 32-bit transactional identifier and 32-bit Essentially, it is a cookie. The correlator is handled
message sequence identifier. Another example is a 64-bit pointer transparently by the FE, i.e., for a particular Request message
to a context block. All such implementation specific use of the the FE MUST assign the same correlator value in the corresponding
correlator is outside the scope of this specification. Response message. In the case where the message from the CE does
not elicit a response, this field may not be useful.
It should be noted that the correlator is transmitted on the The correlator field could be used in many implementations in
network as if it were a 64 bit unsigned integer with the leftmost specific ways by the CE. For example, the CE could split the
or most significant octet (bits 63-56) transmitted first. correlator into a 32-bit transactional identifier and 32-bit
message sequence identifier. Another example is a 64-bit pointer
to a context block. All such implementation-specific uses of the
correlator are outside the scope of this specification.
Whenever the correlator field is not relevant, because no message It should be noted that the correlator is transmitted on the
is expected, the correlator field is set to 0. network as if it were a 64-bit unsigned integer with the leftmost
or most significant octet (bits 63-56) transmitted first.
Flags(32 bits): Whenever the correlator field is not relevant, because no message
Identified so far: is expected, the correlator field is set to 0.
Flags (32 bits):
Identified so far:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |
|ACK| Pri |Rsr |EM |A|TP | Reserved | |ACK| Pri |Rsr |EM |A|TP | Reserved |
| | | vd. | |T| | | | | | vd. | |T| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Flags
- ACK: ACK indicator (2 bit) Figure 13: Header Flags
The ACK indicator flag is only used by the CE when sending a
Config Message (Section 7.6.1) or a HB message (Section 7.10)
to indicate to the message receiver whether or not a response
is required by the sender. Note that for all other messages
than the Config Message or the HB Message this flag MUST be
ignored.
The flag values are defined as below: - ACK: ACK indicator (2 bits)
The ACK indicator flag is only used by the CE when sending a Config
message (Section 7.6.1) or an HB message (Section 7.10) to indicate
to the message receiver whether or not a response is required by the
sender. Note that for all other messages than the Config message or
the HB message this flag MUST be ignored.
'NoACK' (0b00) - to indicate that the message receiver The flag values are defined as follows:
MUST NOT send any response message back to this message
sender.
'SuccessACK'(0b01) - to indicate the message receiver 'NoACK' (0b00) - to indicate that the message receiver MUST NOT
MUST send a response message back only when the message send any Response message back to this message sender.
has been successfully processed by the receiver.
'FailureACK'(0b10) - to indicate the message receiver 'SuccessACK'(0b01) - to indicate that the message receiver MUST
MUST send a response message back only when there is send a Response message back only when the message has been
failure by the receiver in processing (executing) the successfully processed by the receiver.
message. In other words, if the message can be processed
successfully, the sender will not expect any response
from the receiver.
'AlwaysACK' (0b11) - to indicate the message receiver 'FailureACK'(0b10) - to indicate that the message receiver MUST
MUST send a response message. send a Response message back only when there is failure by the
receiver in processing (executing) the message. In other words,
if the message can be processed successfully, the sender will not
expect any response from the receiver.
Note that in above definitions, the term success implies a 'AlwaysACK' (0b11) - to indicate that the message receiver MUST
complete execution without any failure of the message. send a Response message.
Anything else than a complete successful execution is defined
as a failure for the message processing. As a result, for
the execution modes (defined in Section 4.3.1.1) like
execute-all-or-none, execute-until-failure, and continue-
execute-on-failure, if any single operation among several
operations in the same message fails, it will be treated as a
failure and result in a response if the ACK indicator has
been set to 'FailureACK' or 'AlwaysACK'.
Also note that, other than in Config and HB Messages, Note that in above definitions, the term success implies a complete
requirements for responses of messages are all given in a execution without any failure of the message. Anything else than a
default way rather than by ACK flags. The default complete successful execution is defined as a failure for the message
requirements of these messages and the expected responses are processing. As a result, for the execution modes (defined in
summarized below. Detailed descriptions can be found in the Section 4.3.1.1) like execute-all-or-none, execute-until-failure, and
individual message definitions: continue-execute-on-failure, if any single operation among several
operations in the same message fails, it will be treated as a failure
and result in a response if the ACK indicator has been set to
'FailureACK' or 'AlwaysACK'.
+ Association Setup Message always expects a response. Also note that, other than in Config and HB messages, requirements
for responses of messages are all given in a default way rather than
by ACK flags. The default requirements of these messages and the
expected responses are summarized below. Detailed descriptions can
be found in the individual message definitions:
+ Association Setup message always expects a response.
+ Association Teardown Message, and Packet Redirect + Association Teardown Message, and Packet Redirect
Message, never expect responses. message, never expect responses.
+ Query Message always expects a response. + Query message always expects a response.
+ Response message never expects further responses. + Response message never expects further responses.
- Pri: Priority (3 bits) - Pri: Priority (3 bits)
ForCES protocol defines 8 different levels of priority (0-7).
The priority level can be used to distinguish between
different protocol message types as well as between the same
message type. The higher the priority value, the more
important the PDU is. For example, the REDIRECT packet
message could have different priorities to distinguish
between routing protocols packets and ARP packets being
redirected from FE to CE. The Normal priority level is 1.
The different priorities imply messages could be re-ordered;
however, re-ordering is undesirable when it comes to a set of
messages within a transaction and caution should be exercised
to avoid this from happening.
- EM: Execution Mode (2 bits) ForCES protocol defines 8 different levels of priority (0-7). The
There are 3 execution modes refer to Section 4.3.1.1 for priority level can be used to distinguish between different protocol
details. message types as well as between the same message type. The higher
the priority value, the more important the PDU is. For example, the
REDIRECT packet message could have different priorities to
distinguish between routing protocol packets and ARP packets being
redirected from FE to CE. The normal priority level is 1. The
different priorities imply messages could be re-ordered; however,
re-ordering is undesirable when it comes to a set of messages within
a transaction and caution should be exercised to avoid this.
Reserved..................... (0b00) - EM: Execution Mode (2 bits)
`execute-all-or-none` ....... (0b01) There are 3 execution modes; refer to Section 4.3.1.1 for details.
`execute-until-failure` ..... (0b10) Reserved..................... (0b00)
`continue-execute-on-failure` (0b11) `execute-all-or-none` ....... (0b01)
- AT: Atomic Transaction (1 bit) `execute-until-failure` ..... (0b10)
This flag indicates if the message is stand-alone message or
one of multiple messages that belongs to 2PC transaction
operations. See Section 4.3.1.2.2 for details.
Stand-alone message ......... (0b0) `continue-execute-on-failure` (0b11)
2PC transaction message ..... (0b1)
- TP: Transaction Phase (2 bits) - AT: Atomic Transaction (1 bit)
A message from the CE to the FE within a transaction could be
indicative of the different phases the transaction is in.
Refer to Section 4.3.1.2.2 for details.
SOT (start of transaction) ..... (0b00) This flag indicates if the message is a stand-alone message or one of
multiple messages that belong to 2PC transaction operations. See
Section 4.3.1.2.2 for details.
MOT (Middle of transaction) .... (0b01) Stand-alone message ......... (0b0)
EOT (end of transaction) ........(0b10) 2PC transaction message ..... (0b1)
ABT (abort) .....................(0b11) - TP: Transaction Phase (2 bits)
A message from the CE to the FE within a transaction could be
indicative of the different phases the transaction is in. Refer to
Section 4.3.1.2.2 for details.
SOT (start of transaction) ..... (0b00)
MOT (middle of transaction) .... (0b01)
EOT (end of transaction) ........(0b10)
ABT (abort) .....................(0b11)
6.2. Type Length Value (TLV) Structuring 6.2. Type Length Value (TLV) Structuring
TLVs are extensively used by the ForCES protocol. TLVs have some TLVs are extensively used by the ForCES protocol. TLVs have some
very nice properties which make them a good candidate for encoding very nice properties that make them a good candidate for encoding the
the XML definitions of the LFB class model. These are: XML definitions of the LFB class model. These are:
o Providing for binary type-value encoding that is close to the XML o Providing for binary type-value encoding that is close to the XML
string tag-value scheme. string tag-value scheme.
o Allowing for fast generalized binary-parsing functions. o Allowing for fast generalized binary-parsing functions.
o Allowing for forward and backward tag compatibility. This is o Allowing for forward and backward tag compatibility. This is
equivalent to the XML approach i.e old applications can ignore new equivalent to the XML approach, i.e., old applications can ignore
TLVs and newer applications can ignore older TLVs. new TLVs and newer applications can ignore older TLVs.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | | TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Essentially the TLV Data) | | Value (Essentially the TLV Data) |
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: TLV Representation Figure 14: TLV Representation
TLV Type (16): TLV Type (16):
The TLV type field is two octets, and semantically
indicates the type of data encapsulated within the The TLV type field is 2 octets, and semantically indicates the type
TLV. of data encapsulated within the TLV.
TLV Length (16): TLV Length (16):
The TLV length field is two octets, and includes the
length of the TLV type (2 octets), TLV Length (2 The TLV length field is 2 octets, and includes the length of the TLV
octets), and the length of the TLV data found in the type (2 octets), TLV Length (2 octets), and the length of the TLV
value field, in octets. Note that this length is data found in the value field, in octets. Note that this length is
the actual length of the value, before any padding the actual length of the value, before any padding for alignment is
for alignment is added. added.
TLV Value (variable): TLV Value (variable):
The TLV value field carries the data. For
extensibility, the TLV value may in fact be a TLV. The TLV value field carries the data. For extensibility, the TLV
Padding is required when the length is not a value may in fact be a TLV. Padding is required when the length is
multiple of 32 bits, and is the minimum number of not a multiple of 32 bits, and is the minimum number of octets
octets required to bring the TLV to a multiple of 32 required to bring the TLV to a multiple of 32 bits. The length of
bits. The length of the value before padding is the value before padding is indicated by the TLV Length field.
indicated by the TLV Length field. Note: The value
field could be empty which implies the minimal Note: The value field could be empty, which implies the minimal
length a TLV could be is 4 (length of "T" field and length a TLV could be is 4 (length of "T" field and length of "L"
length of "L" field). field).
6.2.1. Nested TLVs 6.2.1. Nested TLVs
TLV values can be other TLVs. This provides the benefits of protocol TLV values can be other TLVs. This provides the benefits of protocol
flexibility (being able to add new extensions by introducing new TLVs flexibility (being able to add new extensions by introducing new TLVs
when needed). The nesting feature also allows for a conceptual when needed). The nesting feature also allows for a conceptual
optimization with the XML LFB definitions to binary PL representation optimization with the XML LFB definitions to binary PL representation
(represented by nested TLVs). (represented by nested TLVs).
6.2.2. Scope of the T in TLV 6.2.2. Scope of the T in TLV
The "Type" values in the TLV are global in scope. This means that There are two global name scopes for the "Type" in the TLV. The
wherever TLVs occur in the PDU, a specific Type value refers to the first name scope is for OPER-TLVs and is defined in A.4 whereas the
same Type of TLV. This is a design choice that was made to ease second name scope is outside OPER-TLVs and is defined in section A.2.
debugging of the protocol.
6.3. ILV 6.3. ILV
A slight variation of the TLV known as the ILV. This sets the type The ILV is a slight variation of the TLV. This sets the type ("T")
("T") to be a 32-bit local index that refers to a ForCES component to be a 32-bit local index that refers to a ForCES component ID
ID. (refer to Section 6.4.1). (refer to Section 6.4.1).
The ILV length field is a 4 octet integer, and includes the length of The ILV length field is a 4-octet integer, and includes the length of
the ILV type (4 octets), ILV Length (4 octets), and the length of the the ILV type (4 octets), ILV Length (4 octets), and the length of the
ILV data found in the value field, in octets. Note that, as in the ILV data found in the value field, in octets. Note that, as in the
case of the TLV, this length is the actual length of the value, case of the TLV, this length is the actual length of the value,
before any padding for alignment is added. before any padding for alignment is added.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 25 skipping to change at page 42, line 5
| Value | | Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ILV Representation Figure 15: ILV Representation
It should be noted that the "I" values are of local scope and are It should be noted that the "I" values are of local scope and are
defined by the data declarations from the LFB definition. Refer to defined by the data declarations from the LFB definition. Refer to
Section 7.1.8 for discussions on usage of ILVs. Section 7.1.8 for discussions on usage of ILVs.
6.4. Important Protocol encapsulations 6.4. Important Protocol Encapsulations
In this section, we review a few encapsulation concepts that are used In this section, we review a few encapsulation concepts that are used
by the ForCES protocol for its operations. by the ForCES protocol for its operations.
We briefly re-introduce two concepts, Paths and Keys, from the model We briefly re-introduce two concepts, paths, and keys, from the
draft [FE-MODEL] in order to provide context. The reader is referred ForCES model [RFC5812] in order to provide context. The reader is
to [FE-MODEL] for a lot of the finer details. referred to [RFC5812] for a lot of the finer details.
For readability reasons, we introduce the encapsulation schemes that For readability reasons, we introduce the encapsulation schemes that
are used to carry content in a protocol message, namely FULLDATA-TLV, are used to carry content in a protocol message, namely, FULLDATA-
SPARSEDATA-TLV, and RESULT-TLV. TLV, SPARSEDATA-TLV, and RESULT-TLV.
6.4.1. Paths 6.4.1. Paths
The model draft [FE-MODEL] defines an XML-based language that allows The ForCES model [RFC5812] defines an XML-based language that allows
for a formal definition of LFBs. This is similar to the relationship for a formal definition of LFBs. This is similar to the relationship
between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB
and ASN.1 being analogous to the XML model language). Any entity and ASN.1 being analogous to the XML model language). Any entity
that the CE configures on an FE MUST be formally defined in an LFB. that the CE configures on an FE MUST be formally defined in an LFB.
These entities could be scalars (e.g., a 32-bit IPv4 address) or These entities could be scalars (e.g., a 32-bit IPv4 address) or
vectors (such as a nexthop table). Each entity within the LFB is vectors (such as a nexthop table). Each entity within the LFB is
given a numeric 32-bit identifier known as an "component id". This given a numeric 32-bit identifier known as a "component id". This
scheme allows the attribute to be "addressed" in a protocol scheme allows the component to be "addressed" in a protocol
construct. construct.
These addressable entities could be hierarchical (e.g., a table These addressable entities could be hierarchical (e.g., a table
column or a cell within a table row). In order to address column or a cell within a table row). In order to address
hierarchical data, the concept of a path is introduced by the model hierarchical data, the concept of a path is introduced by the model
[FE-MODEL]. A path is a series of 32-bit component IDs which are [RFC5812]. A path is a series of 32-bit component IDs that are
typically presented in a dot-notation (e.g., 1.2.3.4). Section typically presented in a dot-notation (e.g., 1.2.3.4). Section 7
(Section 7) formally defines how paths are used to reference data formally defines how paths are used to reference data that is being
that is being encapsulated within a protocol message. encapsulated within a protocol message.
6.4.2. Keys 6.4.2. Keys
The model draft [FE-MODEL] defines two ways to address table rows. The ForCES model [RFC5812] defines two ways to address table rows.
The standard/common mechanism is to allow table rows to be referenced The standard/common mechanism is to allow table rows to be referenced
by a 32-bit index. The secondary mechanism is via Keys which allow by a 32-bit index. The secondary mechanism is via keys that allow
for content addressing. An example key is a multi-field content key for content addressing. An example key is a multi-field content key
that uses the IP address and prefix length to uniquely reference an that uses the IP address and prefix length to uniquely reference an
IPv4 routing table row. In essence, while the common scheme to IPv4 routing table row. In essence, while the common scheme to
address a table row is via its table index, a table row's path could address a table row is via its table index, a table row's path could
be derived from a key. The KEYINFO-TLV (Section 7) is used to carry be derived from a key. The KEYINFO-TLV (Section 7) is used to carry
the data that is used to do the lookup. the data that is used to do the lookup.
6.4.3. DATA TLVs 6.4.3. DATA TLVs
Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV
skipping to change at page 44, line 45 skipping to change at page 43, line 27
A number of operations in ForCES will need to reference optional data A number of operations in ForCES will need to reference optional data
within larger structures. The SPARSEDATA-TLV encoding is provided to within larger structures. The SPARSEDATA-TLV encoding is provided to
make it easier to encapsulate optionally appearing data components. make it easier to encapsulate optionally appearing data components.
Refer to Appendix C for an example of SPARSEDATA-TLV. Refer to Appendix C for an example of SPARSEDATA-TLV.
RESULT-TLVs carry responses back from the FE based on a config issued RESULT-TLVs carry responses back from the FE based on a config issued
by the CE. Refer to Appendix C for examples of RESULT-TLVs and by the CE. Refer to Appendix C for examples of RESULT-TLVs and
Section 7.1.7 for layout. Section 7.1.7 for layout.
6.4.4. Addressing LFB entities 6.4.4. Addressing LFB Entities
Section 6.4.1 and Section 6.4.2 discuss how to target an entity Section 6.4.1 and Section 6.4.2 discuss how to target an entity
within an LFB. However, the addressing mechanism used requires that within an LFB. However, the addressing mechanism used requires that
an LFB type and instance is selected first. The LFB Selector is used an LFB type and instance are selected first. The LFB selector is
to select an LFB type and instance being targeted. Section used to select an LFB type and instance being targeted. Section 7
(Section 7) goes into more details; for our purpose, we illustrate goes into more details; for our purpose, we illustrate this concept
this concept using Figure 16 below. More examples of layouts can be using Figure 16 below. More examples of layouts can be found reading
found reading further into the text (Example: Figure 21). further into the text (example: Figure 22).
main hdr (Message type: example "config") main hdr (Message type: example "config")
| |
| |
| |
+- T = LFBselect +- T = LFBselect
| |
+-- LFBCLASSID (unique per LFB defined) +-- LFBCLASSID (unique per LFB defined)
| |
| |
skipping to change at page 46, line 7 skipping to change at page 44, line 32
| // Refer to the discussion on keys and paths | // Refer to the discussion on keys and paths
| |
| |
+-- The associated data, if any, for the entity +-- The associated data, if any, for the entity
// Refer to discussion on FULL/SPARSE DATA TLVs // Refer to discussion on FULL/SPARSE DATA TLVs
Figure 16: Entity Addressing Figure 16: Entity Addressing
7. Protocol Construction 7. Protocol Construction
A protocol layer PDU consists of a Common Header (defined in Section A protocol layer PDU consists of a common header (defined in
Section 6.1 ) and a message body. The Common Header is followed by a Section 6.1 ) and a message body. The common header is followed by a
message-type-specific message body. Each message body is formed from message-type-specific message body. Each message body is formed from
one or more top-level TLVs. A top-level TLV may contain one or more one or more top-level TLVs. A top-level TLV may contain one or more
sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs,
because they describe an operation to be done. because they describe an operation to be done.
+-------------+---------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
| Message | Top-Level TLV | OPER-TLV(s) | Reference | | Message | Top-Level TLV | OPER-TLV(s) | Reference |
| Name | | | | | Name | | | |
+-------------+---------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
| Association | (LFBselect)* | REPORT | Section 7.5.2 | | Association | (LFBselect)* | REPORT | Section 7.5.1 |
| Setup | | | | | Setup | | | |
| | | | |
| Association | ASRresult-TLV | none | Section 7.5.2 | | Association | ASRresult-TLV | none | Section 7.5.2 |
| Setup | | | | | Setup | | | |
| Response | | | | | Response | | | |
| | | | |
| Association | ASTreason-TLV | none | Section 7.5.3 | | Association | ASTreason-TLV | none | Section 7.5.3 |
| Teardown | | | | | Teardown | | | |
| | | | |
| Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | DEL | COMMIT | | | | | | DEL | COMMIT | | |
| | | TRCOMP)+ | | | | | TRCOMP)+ | |
| | | | |
| Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 | | Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 |
| Response | | SET-PROP-RESPONSE | | | | Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | | | | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | | | | | COMMIT-RESPONSE)+ | |
| | | | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| | | | |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | | | Response | | GET-PROP-RESPONSE)+ | |
| | | | |
| Event | LFBselect | REPORT | Section 7.8 | | Event | LFBselect | REPORT | Section 7.8 |
| Notifi- | | | | | Notifi- | | | |
| cation | | | | | cation | | | |
| | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 | | Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | | | Redirect | | | |
| | | | |
| Heartbeat | none | none | Section 7.10 | | Heartbeat | none | none | Section 7.10 |
+-------------+---------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
Table 1 Table 1
The different messages are illustrated in Table 1. The different The different messages are illustrated in Table 1. The different
message type numerical values are defined in Appendix A.1. All the message type numerical values are defined in Appendix A.1. All the
TLVs values are defined in Appendix A.2. TLV values are defined in Appendix A.2.
An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid
and LFB Instance being referenced as well as the OPER-TLV(s) being and LFB instance being referenced as well as the OPER-TLV(s) being
applied to that reference. applied to that reference.
Each type of OPER-TLV is constrained as to how it describes the paths Each type of OPER-TLV is constrained as to how it describes the paths
and selectors of interest. The following BNF describes the basic and selectors of interest. The following BNF describes the basic
structure of an OPER-TLV and Table 2 gives the details for each type structure of an OPER-TLV and Table 2 gives the details for each type.
OPER-TLV := 1*PATH-DATA-TLV OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA] PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR] PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV 1*PATH-DATA-TLV
KEYINFO-TLV := KeyID FULLDATA-TLV KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data component which may nest FULLDATA-TLV := encoded data component which may nest
further FULLDATA-TLVs further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally SPARSEDATA-TLV := encoded data that may have optionally
appearing components appearing components
RESULT-TLV := Holds result code and optional FULLDATA-TLV RESULT-TLV := Holds result code and optional FULLDATA-TLV
Figure 17: BNF of OPER-TLV Figure 17: BNF of OPER-TLV
o PATH-DATA-TLV identifies the exact component targeted and may have o PATH-DATA-TLV identifies the exact component targeted and may have
zero or more paths associated with it. The last PATH-DATA-TLV in zero or more paths associated with it. The last PATH-DATA-TLV in
the case of nesting of paths via the DATA construct in the case of the case of nesting of paths via the DATA construct in the case of
SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is SET, SET-PROP requests, and GET-RESPONSE/GET-PROP-RESPONSE is
terminated by encoded data or response in the form of either terminated by encoded data or response in the form of either
FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV. FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV.
o PATH provides the path to the data being referenced. o PATH provides the path to the data being referenced.
* flags (16 bits) are used to further refine the operation to be * flags (16 bits) are used to further refine the operation to be
applied on the Path. More on these later. applied on the path. More on these later.
* IDcount(16 bit): count of 32 bit IDs * IDcount (16 bits): count of 32-bit IDs
* IDs: zero or more 32bit IDs (whose count is given by IDcount) * IDs: zero or more 32-bit IDs (whose count is given by IDcount)
defining the main path. Depending on the flags, IDs could be defining the main path. Depending on the flags, IDs could be
field IDs only or a mix of field and dynamic IDs. Zero is used field IDs only or a mix of field and dynamic IDs. Zero is used
for the special case of using the entirety of the containing for the special case of using the entirety of the containing
context as the result of the path. context as the result of the path.
o SELECTOR is an optional construct that further defines the PATH. o SELECTOR is an optional construct that further defines the PATH.
Currently, the only defined selector is the KEYINFO-TLV, used for Currently, the only defined selector is the KEYINFO-TLV, used for
selecting an array entry by the value of a key field. The selecting an array entry by the value of a key field. The
presence of a SELECTOR is correct only when the flags also presence of a SELECTOR is correct only when the flags also
indicate its presence. A mismatch is a protocol format error. indicate its presence.
o A KEYINFO-TLV contains information used in content keying. o A KEYINFO-TLV contains information used in content keying.
* A KeyID is used in a KEYINFO-TLV. It indicates which key for * A 32-bit KeyID is used in a KEYINFO-TLV. It indicates which
the current array is being used as the content key for array key for the current array is being used as the content key for
entry selection. array entry selection.
* The key's data is the data to look for in the array, in the * The key's data is the data to look for in the array, in the
fields identified by the key field. The information is encoded fields identified by the key field. The information is encoded
according to the rules for the contents of a FULLDATA-TLV, and according to the rules for the contents of a FULLDATA-TLV, and
represent the field or fields which make up the key identified represents the field or fields that make up the key identified
by the KeyID. by the KeyID.
o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV, or
or more further PATH-DATA selection. FULLDATA-TLV and SPARSEDATA- 1 or more further PATH-DATA selections. FULLDATA-TLV and
TLV are only allowed on SET or SET-PROP requests, or on responses SPARSEDATA-TLV are only allowed on SET or SET-PROP requests, or on
which return content information (GET-RESPONSE for example). responses that return content information (GET-RESPONSE, for
PATH-DATA may be included to extend the path on any request. example). PATH-DATA may be included to extend the path on any
request.
* Note: Nested PATH-DATA-TLVs are supported as an efficiency * Note: Nested PATH-DATA-TLVs are supported as an efficiency
measure to permit common subexpression extraction. measure to permit common subexpression extraction.
* FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path * FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path
has been selected by the PATH. Refer to Section 7.1 for has been selected by the PATH. Refer to Section 7.1 for
details. details.
* The following table summarizes the applicability and * The following table summarizes the applicability and
restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to
the OPER-TLVs. the OPER-TLVs.
+-------------------+-------------------------------+---------------+ +-------------------+-------------------------------+---------------+
| OPER-TLV | DATA TLV | RESULT-TLV | | OPER-TLV | DATA TLV | RESULT-TLV |
+-------------------+-------------------------------+---------------+ +-------------------+-------------------------------+---------------+
| SET | (FULLDATA-TLV | | none | | SET | | none |
| | SPARSEDATA-TLV)+ | |
| | | |
| SET-PROP | (FULLDATA-TLV | | none | | SET-PROP | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | | | | SPARSEDATA-TLV)+ | |
| | | |
| SET-RESPONSE | none | (RESULT-TLV)+ | | SET-RESPONSE | none | (RESULT-TLV)+ |
| | | |
| SET-PROP-RESPONSE | none | (RESULT-TLV)+ | | SET-PROP-RESPONSE | none | (RESULT-TLV)+ |
| | | | | DEL | | none |
| DEL | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | |
| | | |
| DEL-RESPONSE | none | (RESULT-TLV)+ | | DEL-RESPONSE | none | (RESULT-TLV)+ |
| | | |
| GET | none | none | | GET | none | none |
| | | |
| GET-PROP | none | none | | GET-PROP | none | none |
| | | |
| GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| | | |
| GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| | | |
| REPORT | (FULLDATA-TLV)+ | none | | REPORT | (FULLDATA-TLV)+ | none |
| | | |
| COMMIT | none | none | | COMMIT | none | none |
| | | |
| COMMIT-RESPONSE | none | (RESULT-TLV)+ | | COMMIT-RESPONSE | none | (RESULT-TLV)+ |
| | | |
| TRCOMP | none | none | | TRCOMP | none | none |
+-------------------+-------------------------------+---------------+ +-------------------+-------------------------------+---------------+
Table 2 Table 2
o RESULT-TLV contains the indication of whether the individual SET o RESULT-TLV contains the indication of whether the individual SET
or SET-PROP succeeded. RESULT-TLV is included on the assumption or SET-PROP succeeded. RESULT-TLV is included on the assumption
that individual parts of a SET request can succeed or fail that individual parts of a SET request can succeed or fail
separately. separately.
In summary this approach has the following characteristic: In summary, this approach has the following characteristics:
o There can be one or more LFB class ID and instance ID combination o There can be one or more LFB class ID and instance ID combinations
targeted in a message (batch) targeted in a message (batch).
o There can one or more operations on an addressed LFB class ID/ o There can one or more operations on an addressed LFB class ID/
instance ID combination (batch) instance ID combination (batch).
o There can be one or more path targets per operation (batch) o There can be one or more path targets per operation (batch).
o Paths may have zero or more data values associated (flexibility o Paths may have zero or more data values associated (flexibility
and operation specific) and operation specific).
It should be noted that the above is optimized for the case of a It should be noted that the above is optimized for the case of a
single LFB class ID and instance ID targeting. To target multiple single LFB class ID and instance ID targeting. To target multiple
instances within the same class, multiple LFBselects are needed. instances within the same class, multiple LFBselects are needed.
7.1. Discussion on encoding 7.1. Discussion on Encoding
Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV
and SPARSEDATA-TLV) and the justifications for their existence. In and SPARSEDATA-TLV) and the justifications for their existence. In
this section we explain how they are encoded. this section, we explain how they are encoded.
7.1.1. Data Packing Rules 7.1.1. Data Packing Rules
The scheme for encoding data used in this doc adheres to the The scheme for encoding data used in this document adheres to the
following rules: following rules:
o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being
transported. This data will be as was described in the LFB transported. This data will be as was described in the LFB
definition. definition.
o Variable sized data within a FULLDATA-TLV will be encapsulated o Variable-sized data within a FULLDATA-TLV will be encapsulated
inside another FULLDATA-TLV inside the V of the outer TLV. For inside another FULLDATA-TLV inside the V of the outer TLV. For an
example of such a setup refer to Appendix C and Appendix D example of such a setup, refer to Appendices C and D.
o In the case of FULLDATA-TLVs: o In the case of FULLDATA-TLVs:
* When a table is referred to in the PATH (IDs) of a PATH-DATA- * When a table is referred to in the PATH (IDs) of a PATH-DATA-
TLV, then the FULLDATA-TLV's "V" will contain that table's row TLV, then the FULLDATA-TLV's "V" will contain that table's row
content prefixed by its 32 bit index/subscript. On the other content prefixed by its 32-bit index/subscript. On the other
hand, when PATH flags are 00, the PATH may contain an index hand, the PATH may contain an index pointing to a row in table;
pointing to a row in table; in such a case, the FULLDATA-TLV's in such a case, the FULLDATA-TLV's "V" will only contain the
"V" will only contain the content with the index in order to content with the index in order to avoid ambiguity.
avoid ambiguity.
7.1.2. Path Flags 7.1.2. Path Flags
The following flags are currently defined: Only bit 0, the SELECTOR Bit, is currently used in the path flags as
illustrated in Figure 18.
o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 0 1
following this path information, and should be considered in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
evaluating the path. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
|S| Reserved |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.1.3. Relation of operational flags with global message flags Figure 18: Path Flags
The semantics of the flag are defined as follows:
o SELECTOR Bit: F_SELKEY(set to 1) indicates that a KEY Selector is
present following this path information, and should be considered
in evaluating the path content.
7.1.3. Relation of Operational Flags with Global Message Flags
Global flags, such as the execution mode and the atomicity indicators Global flags, such as the execution mode and the atomicity indicators
defined in the header, apply to all operations in a message. Global defined in the header, apply to all operations in a message. Global
flags provide semantics that are orthogonal to those provided by the flags provide semantics that are orthogonal to those provided by the
operational flags, such as the flags defined in Path Data. The scope operational flags, such as the flags defined in path-data. The scope
of operational flags is restricted to the operation. of operational flags is restricted to the operation.
7.1.4. Content Path Selection 7.1.4. Content Path Selection
The KEYINFO-TLV describes the KEY as well as associated KEY data. The KEYINFO-TLV describes the KEY as well as associated KEY data.
KEYs, used for content searches, are restricted and described in the KEYs, used for content searches, are restricted and described in the
LFB definition. LFB definition.
7.1.5. LFBselect-TLV 7.1.5. LFBselect-TLV
The LFBselect TLV is an instance of a TLV as defined in Section 6.2. The LFBselect TLV is an instance of a TLV as defined in Section 6.2.
The definition is as below: The definition is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFBselect | Length | | Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV | | OPER-TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV | | OPER-TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: PL PDU layout Figure 19: PL PDU Layout
Type: Type:
The type of the TLV is "LFBselect"
The type of the TLV is "LFBselect"
Length: Length:
Length of the TLV including the T and L fields, in octets.
Length of the TLV including the T and L fields, in octets.
LFB Class ID: LFB Class ID:
This field uniquely recognizes the LFB class/type.
This field uniquely recognizes the LFB class/type.
LFB Instance ID: LFB Instance ID:
This field uniquely identifies the LFB instance.
This field uniquely identifies the LFB instance.
OPER-TLV: OPER-TLV:
It describes an operation nested in the LFBselect TLV. Note that
usually there SHOULD be at least one OPER-TLV present for an LFB It describes an operation nested in the LFBselect TLV. Note that
select TLV, but for the Association Setup Message defined in usually there SHOULD be at least one OPER-TLV present for an LFB
Section 7.5.1 where the OPER-TLV is optional. select TLV.
7.1.6. OPER-TLV 7.1.6. OPER-TLV
The OPER-TLV is a place holder in the grammar for TLVs that define The OPER-TLV is a place holder in the grammar for TLVs that define
operations. The different types are defined in Table 3, below. operations. The different types are defined in Table 3, below.
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments | | OPER-TLV | TLV | Comments |
| | "Type" | | | | "Type" | |
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or | | SET | 0x0001 | From CE to FE. Used to create or |
| | | add or update attributes | | | | add or update components |
| | | |
| SET-PROP | 0x0002 | From CE to FE. Used to create or | | SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | add or update attribute properties | | | | add or update component properties |
| | | |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET | | | | response of a SET |
| | | |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP | | | | response of a SET-PROP |
| | | |
| DEL | 0x0005 | From CE to FE. Used to delete or | | DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an attribute | | | | remove an component |
| | | |
| DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry |
| | | response of a DEL | | | | response of a DEL |
| | | |
| GET | 0x0007 | From CE to FE. Used to retrieve an | | GET | 0x0007 | From CE to FE. Used to retrieve an |
| | | attribute | | | | component |
| | | |
| GET-PROP | 0x0008 | From CE to FE. Used to retrieve an | | GET-PROP | 0x0008 | From CE to FE. Used to retrieve an |
| | | attribute property | | | | component property |
| | | |
| GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry |
| | | response of a GET | | | | response of a GET |
| | | |
| GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry | | GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry |
| | | response of a GET-PROP | | | | response of a GET-PROP |
| | | |
| REPORT | 0x000B | From FE to CE. Used to carry an | | REPORT | 0x000B | From FE to CE. Used to carry an |
| | | asynchronous event | | | | asynchronous event |
| | | |
| COMMIT | 0x000C | From CE to FE. Used to issue a | | COMMIT | 0x000C | From CE to FE. Used to issue a |
| | | commit in a 2PC transaction | | | | commit in a 2PC transaction |
| | | | | COMMIT-RESPONSE | 0x000D | From FE to CE. Used to confirm a |
| COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to confirm a |
| | | commit in a 2PC transaction | | | | commit in a 2PC transaction |
| | | |
| TRCOMP | 0x000E | From CE to FE. Used to indicate | | TRCOMP | 0x000E | From CE to FE. Used to indicate |
| | | NE-wide success of 2PC transaction | | | | NE-wide success of 2PC transaction |
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
Table 3 Table 3
Different messages define OPER-TLV are valid and how they are used Different messages use OPER-TLV and define how they are used (refer
(refer to Table 1 and Table 2). to Table 1 and Table 2).
SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do
not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP- not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP-
RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs. RESPONSE, and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs.
A GET-RESPONSE in response to a successful GET will have FULLDATA- A GET-RESPONSE in response to a successful GET will have FULLDATA-
TLVs added to the leaf paths to carry the requested data. For GET TLVs added to the leaf paths to carry the requested data. For GET
operations that fail, instead of the FULLDATA-TLV there will be a operations that fail, instead of the FULLDATA-TLV there will be a
RESULT-TLV. RESULT-TLV.
For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV or For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA-TLV or
SPARSEDATA-TLV in the original request will be replaced with a SPARSEDATA-TLV in the original request will be replaced with a
RESULT-TLV in the response. If the request set the FailureACK flag, RESULT-TLV in the response. If the request set the FailureACK flag,
then only those items which failed will appear in the response. If then only those items that failed will appear in the response. If
the request was for AlwaysACK, then all components of the request the request was for AlwaysACK, then all components of the request
will appear in the response with RESULT-TLVs. will appear in the response with RESULT-TLVs.
Note that if a SET/SET-PROP request with a structure in a FULLDATA- Note that if a SET/SET-PROP request with a structure in a FULLDATA-
TLV is issued, and some field in the structure is invalid, the FE TLV is issued, and some field in the structure is invalid, the FE
will not attempt to indicate which field was invalid, but rather will will not attempt to indicate which field was invalid, but rather will
indicate that the operation failed. Note further that if there are indicate that the operation failed. Note further that if there are
multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can
select which error it chooses to return. So if a FULLDATA-TLV for a select which error it chooses to return. So if a FULLDATA-TLV for a
SET/SET-PROP of a structure attempts to write one field which is read SET/SET-PROP of a structure attempts to write one field that is read
only, and attempts to set another field to an invalid value, the FE only, and attempts to set another field to an invalid value, the FE
can return indication of either error. can return indication of either error.
A SET/SET-PROP operation on a variable length component with a length A SET/SET-PROP operation on a variable-length component with a length
of 0 for the item is not the same as deleting it. If the CE wishes of 0 for the item is not the same as deleting it. If the CE wishes
to delete then the DEL operation should be used whether the path to delete, then the DEL operation should be used whether the path
refers to an array component or an optional structure component. refers to an array component or an optional structure component.
7.1.7. RESULT TLV 7.1.7. RESULT TLV
The RESULT-TLV is an instance of TLV defined in Section 6.2. The The RESULT-TLV is an instance of TLV defined in Section 6.2. The
definition is as below: definition is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RESULT-TLV | Length | | Type = RESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved | | Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: RESULT-TLV Figure 20: RESULT-TLV
Defined Result Values Defined Result Values
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition | | Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success | | E_SUCCESS | 0x00 | Success |
| | | |
| E_INVALID_HEADER | 0x01 | Unspecified error with | | E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. | | | | header. |
| | | |
| E_LENGTH_MISMATCH | 0x02 | Header length field | | E_LENGTH_MISMATCH | 0x02 | Header length field |
| | | does not match actual | | | | does not match actual |
| | | packet length. | | | | packet length. |
| | | |
| E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch |
| | | in versions. | | | | in versions. |
| | | |
| E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is |
| | | invalid for the message | | | | invalid for the message |
| | | receiver. | | | | receiver. |
| | | |
| E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not |
| | | known by receiver. | | | | known by receiver. |
| | | |
| E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known |
| | | by receiver but not | | | | by receiver but not |
| | | currently in use. | | | | currently in use. |
| | | |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified | | | | but the specified |
| | | instance of that class | | | | instance of that class |
| | | does not exist. | | | | does not exist. |
| | | |
| E_INVALID_PATH | 0x08 | The specified path is | | E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. | | | | impossible. |
| | | |
| E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is | | E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is |
| | | possible but the | | | | possible but the |
| | | component does not | | | | component does not |
| | | exist (e.g., attempt to | | | | exist (e.g., attempt to |
| | | modify a table row that | | | | modify a table row that |
| | | has not been created). | | | | has not been created). |
| | | |
| E_EXISTS | 0x0A | The specified object | | E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot | | | | exists but it cannot |
| | | exist for the operation | | | | exist for the operation |
| | | to succeed (e.g., | | | | to succeed (e.g., |
| | | attempt to add an | | | | attempt to add an |
| | | existing LFB instance | | | | existing LFB instance |
| | | or array subscript). | | | | or array subscript). |
| | | |
| E_NOT_FOUND | 0x0B | The specified object | | E_NOT_FOUND | 0x0B | The specified object |
| | | does not exist but it | | | | does not exist but it |
| | | MUST exist for the | | | | MUST exist for the |
| | | operation to succeed | | | | operation to succeed |
| | | (e.g., attempt to | | | | (e.g., attempt to |
| | | delete a non-existing | | | | delete a non-existing |
| | | LFB instance or array | | | | LFB instance or array |
| | | subscript). | | | | subscript). |
| | | |
| E_READ_ONLY | 0x0C | Attempt to modify a | | E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. | | | | read-only value. |
| | | |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
| | | array with an unallowed | | | | array with an unallowed |
| | | subscript. | | | | subscript. |
| | | |
| E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a |
| | | parameter to a value | | | | parameter to a value |
| | | outside of its | | | | outside of its |
| | | allowable range. | | | | allowable range. |
| | | |
| E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write |
| | | contents larger than | | | | contents larger than |
| | | the target object space | | | | the target object space |
| | | (i.e., exceeding a | | | | (i.e., exceeding a |
| | | buffer). | | | | buffer). |
| | | |
| E_INVALID_PARAMETERS | 0x10 | Any other error with | | E_INVALID_PARAMETERS | 0x10 | Any other error with |
| | | data parameters. | | | | data parameters. |
| | | |
| E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not |
| | | acceptable. | | | | acceptable. |
| | | |
| E_INVALID_FLAGS | 0x12 | Message flags are not | | E_INVALID_FLAGS | 0x12 | Message flags are not |
| | | acceptable for the | | | | acceptable for the |
| | | given message type. | | | | given message type. |
| | | |
| E_INVALID_TLV | 0x13 | A TLV is not acceptable | | E_INVALID_TLV | 0x13 | A TLV is not acceptable |
| | | for the given message | | | | for the given message |
| | | type. | | | | type. |
| E_EVENT_ERROR | 0x14 | Unspecified error while | | E_EVENT_ERROR | 0x14 | Unspecified error while |
| | | handling an event. | | | | handling an event. |
| | | |
| E_NOT_SUPPORTED | 0x15 | Attempt to perform a | | E_NOT_SUPPORTED | 0x15 | Attempt to perform a |
| | | valid ForCES operation | | | | valid ForCES operation |
| | | that is unsupported by | | | | that is unsupported by |
| | | the message receiver. | | | | the message receiver. |
| | | |
| E_MEMORY_ERROR | 0x16 | A memory error occurred | | E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a | | | | while processing a |
| | | message (no error | | | | message (no error |
| | | detected in the message | | | | detected in the message |
| | | itself) | | | | itself). |
| | | |
| E_INTERNAL_ERROR | 0x17 | An unspecified error | | E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occurred while | | | | occurred while |
| | | processing a message | | | | processing a message |
| | | (no error detected in | | | | (no error detected in |
| | | the message itself) | | | | the message itself). |
| | | |
| - | 0x18-0xFE | Reserved | | - | 0x18-0xFE | Reserved |
| | | |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE can not | | | | when the FE cannot |
| | | decide what went wrong) | | | | decide what went |
| | | wrong). |
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
Table 4 Table 4
7.1.8. DATA TLV 7.1.8. DATA TLV
A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit Length followed by A FULLDATA-TLV has "T"= FULLDATA-TLV and a 16-bit length followed by
the data value/contents. Likewise, a SPARSEDATA-TLV has "T" = the data value/contents. Likewise, a SPARSEDATA-TLV has "T" =
SPARSEDATA-TLV, a 16-bit Length, followed by the data value/contents. SPARSEDATA-TLV, a 16-bit length, followed by the data value/contents.
In the case of the SPARSEDATA-TLV, each component in the Value part In the case of the SPARSEDATA-TLV, each component in the Value part
of the TLV will be further encapsulated in an ILV. of the TLV will be further encapsulated in an ILV.
Below are the encoding rules for the FULLDATA-TLV and SPARSEDATA- Below are the encoding rules for the FULLDATA-TLV and SPARSEDATA-
TLVs. Appendix C is very useful in illustrating these rules: TLVs. Appendix C is very useful in illustrating these rules:
1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 1. Both ILVs and TLVs MUST be 32-bit aligned. Any padding bits used
for the alignment MUST be zero on transmission and MUST be for the alignment MUST be zero on transmission and MUST be
ignored upon reception. ignored upon reception.
2. FULLDATA-TLVs may be used at a particular path only if every 2. FULLDATA-TLVs may be used at a particular path only if every
component at that path level is present. In example 1(c) of component at that path level is present. In example 1(c) of
Appendix C this concept is illustrated by the presence of all Appendix C, this concept is illustrated by the presence of all
components of the structure S in the FULLDATA-TLV encoding. This components of the structure S in the FULLDATA-TLV encoding. This
requirement holds regardless of whether the fields are fixed or requirement holds regardless of whether the fields are fixed or
variable length, mandatory or optional. variable length, mandatory or optional.
* If a FULLDATA-TLV is used, the encoder MUST lay out data for * If a FULLDATA-TLV is used, the encoder MUST lay out data for
each component in the same order in which the data was each component in the same order in which the data was
defined in the LFB specification. This ensures the decoder defined in the LFB specification. This ensures the decoder
is able to retrieve the data. To use the example 1 again in is able to retrieve the data. To use the example 1 again in
Appendix C, this implies the encoder/decoder is assumed to Appendix C, this implies the encoder/decoder is assumed to
have knowledge of how structure S is laid out in the have knowledge of how structure S is laid out in the
definition. definition.
* In the case of a SPARSEDATA-TLV, it does not need to be * In the case of a SPARSEDATA-TLV, it does not need to be
ordered since the "I" in the ILV uniquely identifies the ordered since the "I" in the ILV uniquely identifies the
component. Examples 1(a) and 1(b) in Appendix C illustrate component. Examples 1(a) and 1(b) in Appendix C illustrate
the power of SPARSEDATA-TLV encoding. the power of SPARSEDATA-TLV encoding.
3. Inside a FULLDATA-TLV 3. Inside a FULLDATA-TLV
* The values for atomic, fixed-length fields are given without * The values for atomic, fixed-length fields are given without
any TLV or ILV encapsulation. any TLV encapsulation.
* The values for atomic, variable-length fields are given * The values for atomic, variable-length fields are given
inside FULLDATA-TLVs. inside FULLDATA-TLVs.
* The values for arrays are in the form of index/subscript,
followed by value as stated in "Data Packing Rules"
(Section 7.1.1) and demonstrated by the examples in the
appendices.
4. Inside a SPARSEDATA-TLV 4. Inside a SPARSEDATA-TLV
* The values for atomic fields may be given with ILVs (32-bit * The values of all fields MUST be given with ILVs (32-bit
index, 32-bit length) index, 32-bit length).
5. Any of the FULLDATA-TLVs can contain an ILV but an ILV cannot 5. FULLDATA-TLVs cannot contain an ILV.
contain a FULLDATA-TLV. This is because it is hard to
disambiguate the ILV since an I is 32 bits and a T is 16 bits.
6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable sized 6. A FULLDATA-TLV can also contain a FULLDATA-TLV for variable-sized
components. The decoding disambiguation is assumed from rule #3 components. The decoding disambiguation is assumed from rule #3
above. above.
7.1.9. SET and GET Relationship 7.1.9. SET and GET Relationship
It is expected that a GET-RESPONSE would satisfy the following: It is expected that a GET-RESPONSE would satisfy the following:
o It would have exactly the same path definitions as those sent in o It would have exactly the same path definitions as those sent in
the GET. The only difference being a GET-RESPONSE will contain the GET. The only difference is that a GET-RESPONSE will contain
FULLDATA-TLVs. FULLDATA-TLVs.
o It should be possible to take the same GET-RESPONSE and convert o It should be possible to take the same GET-RESPONSE and convert
it to a SET successfully by merely changing the T in the it to a SET successfully by merely changing the T in the
operational TLV. operational TLV.
o There are exceptions to this rule: o There are exceptions to this rule:
1. When a KEY selector is used with a path in a GET operation, 1. When a KEY selector is used with a path in a GET operation,
that selector is not returned in the GET-RESPONSE; instead that selector is not returned in the GET-RESPONSE; instead,
the cooked result is returned. Refer to the examples using the cooked result is returned. Refer to the examples using
KEYS to see this. KEYS to see this.
2. When dumping a whole table in a GET, the GET-RESPONSE that 2. When dumping a whole table in a GET, the GET-RESPONSE that
merely edits the T to be SET will end up overwriting the merely edits the T to be SET will end up overwriting the
table. table.
7.2. Protocol Encoding Visualization 7.2. Protocol Encoding Visualization
The figure below shows a general layout of the PL PDU. A main header The figure below shows a general layout of the PL PDU. A main header
is followed by one or more LFB selections each of which may contain is followed by one or more LFB selections each of which may contain
one or more operation. one or more operations.
main hdr (Config in this case) main hdr (Config in this case)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID | +-- LFBCLASSID
| | | |
| | | |
| +-- LFBInstance | +-- LFBInstance
skipping to change at page 61, line 4 skipping to change at page 57, line 52
| |
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID +-- LFBCLASSID
| |
+-- LFBInstance +-- LFBInstance
. .
. .
. .
Figure 21: PL PDU Logical Layout
Figure 20: PL PDU logical layout
The figure below shows a more detailed example of the general layout The figure below shows a more detailed example of the general layout
of the operation within a targeted LFB selection. The idea is to of the operation within a targeted LFB selection. The idea is to
show the different nesting levels a path could take to get to the show the different nesting levels a path could take to get to the
target path. target path.
T = SET T = SET
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
skipping to change at page 62, line 38 skipping to change at page 59, line 38
+ -- IDs + -- IDs
+ -- T = KEYINFO-TLV + -- T = KEYINFO-TLV
| + -- KEY_ID | + -- KEY_ID
| + -- KEY_DATA | + -- KEY_DATA
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
Figure 21: Sample operation layout Figure 22: Sample Operation Layout
Appendix D shows a more concise set of use-cases on how the data Appendix D shows a more concise set of use cases on how the data
encoding is done. encoding is done.
7.3. Core ForCES LFBs 7.3. Core ForCES LFBs
There are two LFBs that are used to control the operation of the There are two LFBs that are used to control the operation of the
ForCES protocol and to interact with FEs and CEs: ForCES protocol and to interact with FEs and CEs:
o FE Protocol LFB o FE Protocol LFB
o FE Object LFB o FE Object LFB
Although these LFBs have the same form and interface as other LFBs, Although these LFBs have the same form and interface as other LFBs,
they are special in many respects. They have fixed well-known LFB they are special in many respects. They have fixed well-known LFB
Class and Instance IDs. They are statically defined (no dynamic Class and Instance IDs. They are statically defined (no dynamic
instantiation allowed) and their status cannot be changed by the instantiation allowed), and their status cannot be changed by the
protocol: any operation to change the state of such LFBs (for protocol: any operation to change the state of such LFBs (for
instance, in order to disable the LFB) MUST result in an error. instance, in order to disable the LFB) MUST result in an error.
Moreover, these LFBs MUST exist before the first ForCES message can Moreover, these LFBs MUST exist before the first ForCES message can
be sent or received. All attributes in these LFBs MUST have pre- be sent or received. All components in these LFBs MUST have pre-
defined default values. Finally, these LFBs do not have input or defined default values. Finally, these LFBs do not have input or
output ports and do not integrate into the intra-FE LFB topology. output ports and do not integrate into the intra-FE LFB topology.
7.3.1. FE Protocol LFB 7.3.1. FE Protocol LFB
The FE Protocol LFB is a logical entity in each FE that is used to The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB Class ID is control the ForCES protocol. The FE Protocol LFB Class ID is
assigned the value 0x2. The FE Protocol LFB Instance ID is assigned assigned the value 0x2. The FE Protocol LFB Instance ID is assigned
the value 0x1. There MUST be one and only one instance of the FE the value 0x1. There MUST be one and only one instance of the FE
Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB in an FE. The values of the components in the FE
Protocol LFB have pre-defined default values that are specified here. Protocol LFB have pre-defined default values that are specified here.
Unless explicit changes are made to these values using Config Unless explicit changes are made to these values using Config
messages from the CE, these default values MUST be used for correct messages from the CE, these default values MUST be used for correct
operation of the protocol. operation of the protocol.
The formal definition of the FE Protocol Object LFB can be found in The formal definition of the FE Protocol Object LFB can be found in
Appendix B. Appendix B.
7.3.1.1. FE Protocol capabilities 7.3.1.1. FE Protocol Capabilities
FE Protocol capabilities are read-only. FE Protocol capabilities are read-only.
7.3.1.1.1. SupportableVersions 7.3.1.1.1. SupportableVersions
ForCES protocol version(s) supported by the FE ForCES protocol version(s) supported by the FE.
7.3.1.1.2. FE Protocol Attributes 7.3.1.1.2. FE Protocol Components
FE Protocol attributes (can be read and set). FE Protocol components (can be read and set).
7.3.1.1.2.1. CurrentRunningVersion 7.3.1.1.2.1. CurrentRunningVersion
Current running version of the ForCES protocol Current running version of the ForCES protocol.
7.3.1.1.2.2. FEID 7.3.1.1.2.2. FEID
FE unicast ID FE unicast ID.
7.3.1.1.2.3. MulticastFEIDs 7.3.1.1.2.3. MulticastFEIDs
FE multicast ID(s) list - this is a list of multicast IDs that the FE FE multicast ID(s) list - This is a list of multicast IDs to which
belongs to. These IDs are configured by the CE. the FE belongs. These IDs are configured by the CE.
7.3.1.1.2.4. CEHBPolicy 7.3.1.1.2.4. CEHBPolicy
CE heartbeat policy - This policy, along with the parameter 'CE CE heartbeat policy - This policy, along with the parameter 'CE
Heartbeat Dead Interval (CE HDI)' as described below defines the Heartbeat Dead Interval (CE HDI)' as described below, defines the
operating parameters for the FE to check the CE liveness. The policy operating parameters for the FE to check the CE liveness. The policy
values with meanings are listed as below: values with meanings are listed as follows:
o 0 (default) - This policy specifies that the CE will send a o 0 (default) - This policy specifies that the CE will send a
Heartbeat Message to the FE(s) whenever the CE reaches a time Heartbeat message to the FE(s) whenever the CE reaches a time
interval within which no other PL messages were sent from the CE interval within which no other PL messages were sent from the CE
to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. to the FE(s); refer to Section 4.3.3 and Section 7.10 for details.
The CE HDI attribute as described below is tied to this policy. The CE HDI component as described below is tied to this policy.
o 1 - The CE will not generate any HB messages. This actually means o 1 - The CE will not generate any HB messages. This actually means
CE does not want the FE to check the CE liveness. that the CE does not want the FE to check the CE liveness.
o Others - reserved. o Others - Reserved.
7.3.1.1.2.5. CEHDI 7.3.1.1.2.5. CEHDI
CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses
to check the CE liveness. If FE has not received any messages from to check the CE liveness. If FE has not received any messages from
CE within this time interval, FE deduces lost connectivity which CE within this time interval, FE deduces lost connectivity, which
implies that the CE is dead or the association to the CE is lost. implies that the CE is dead or the association to the CE is lost.
Default value 30 s. Default value is 30 s.
7.3.1.1.2.6. FEHBPolicy 7.3.1.1.2.6. FEHBPolicy
FE heartbeat policy - This policy, along with the parameter 'FE FE heartbeat policy - This policy, along with the parameter 'FE
Heartbeat Interval (FE HI)', defines the operating parameters for how Heartbeat Interval (FE HI)', defines the operating parameters for how
the FE should behave so that the CE can deduce its liveness. The the FE should behave so that the CE can deduce its liveness. The
policy values and the meanings are: policy values and the meanings are:
o 0 (default) - The FE should not generate any Heartbeat messages. o 0 (default) - The FE should not generate any Heartbeat messages.
In this scenario, the CE is responsible for checking FE liveness In this scenario, the CE is responsible for checking FE liveness
by setting the PL header ACK flag of the message it sends to by setting the PL header ACK flag of the message it sends to
AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat AlwaysACK. The FE responds to the CE whenever the CE sends such
Request Message. Refer to Section 7.10 and Section 4.3.3 for Heartbeat Request messages. Refer to Section 7.10 and
details. Section 4.3.3 for details.
o 1 - This policy specifies that FE MUST actively send a Heartbeat o 1 - This policy specifies that the FE MUST actively send a
Message if it reaches the time interval assigned by the FE HI as Heartbeat message if it reaches the time interval assigned by the
long as no other messages were sent from FE to CE during that FE HI as long as no other messages were sent from the FE to the CE
interval as described in Section 4.3.3. during that interval as described in Section 4.3.3.
o Others - Reserved. o Others - Reserved.
7.3.1.1.2.7. FEHI 7.3.1.1.2.7. FEHI
FE Heartbeat Interval (FE HI) - The time interval the FE should use FE Heartbeat Interval (FE HI) - The time interval the FE should use
to send HB as long as no other messages were sent from FE to CE to send HB as long as no other messages were sent from the FE to the
during that interval as described in Section 4.3.3. The default CE during that interval as described in Section 4.3.3. The default
value for an FE HI is 500ms. value for an FE HI is 500 ms.
7.3.1.1.2.8. CEID 7.3.1.1.2.8. CEID
Primary CEID - The CEID that the FE is associated with. Primary CEID - The CEID with which the FE is associated.
7.3.1.1.2.9. LastCEID 7.3.1.1.2.9. LastCEID
Last Primary CEID - The CEID of the last CE that that the FE Last Primary CEID - The CEID of the last CE with which the FE
associated with. This CE ID is reported to the new Primary CEID. associated. This CE ID is reported to the new Primary CEID.
7.3.1.1.2.10. BackupCEs 7.3.1.1.2.10. BackupCEs
The list of backup CEs an FE can use as backups. Refer to Section 8 The list of backup CEs an FE can use as backups. Refer to Section 8
for details. for details.
7.3.1.1.2.11. CEFailoverPolicy 7.3.1.1.2.11. CEFailoverPolicy
CE failover policy - This specifies the behavior of the FE when the CE failover policy - This specifies the behavior of the FE when the
association with the CE is lost. There is a very tight relation association with the CE is lost. There is a very tight relation
between CE failover policy and Section 7.3.1.1.2.8, between CE failover policy and Section 7.3.1.1.2.8,
Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an
association is lost, depending on configuration, one of the policies association is lost, depending on configuration, one of the policies
listed below is activated. listed below is activated.
o 0 (default) - FE should stop functioning immediately and o 0 (default) - The FE should stop functioning immediately and
transition to FE OperDisable. transition to FE OperDisable.
o 1 - The FE should continue running and do what it can even without o 1 - The FE should continue running and do what it can even without
an associated CE. This basically requires that the FE support CE an associated CE. This basically requires that the FE support CE
Graceful restart (and defines such support in its capabilities). Graceful restart (and defines such support in its capabilities).
If the CEFTI expires before the FE re-associates with either the If the CEFTI expires before the FE re-associates with either the
primary (Section 7.3.1.1.2.8) or one of possibly several backup primary CEID (Section 7.3.1.1.2.8) or one of possibly several
CEs (Section 7.3.1.1.2.10), the FE will go operationally down. backup CEs (Section 7.3.1.1.2.10), the FE will go operationally
down.
o Others - Reserved o Others - Reserved.
7.3.1.1.2.12. CEFTI 7.3.1.1.2.12. CEFTI
CE Failover Timeout Interval (CEFTI) - The time interval associated CE Failover Timeout Interval (CEFTI) - The time interval associated
with the CE failover policy case '0' and '2'. The default value is with the CE failover policy case '0' and '1'. The default value is
set to 300 seconds. Note that it is advisable to set the CEFTI value set to 300 seconds. Note that it is advisable to set the CEFTI value
much higher than the CE Heartbeat Dead Interval (CE HDI) since the much higher than the CE Heartbeat Dead Interval (CE HDI) since the
effect of expiring this parameter is devastating to the operation of effect of expiring this parameter is devastating to the operation of
the FE. the FE.
7.3.1.1.2.13. FERestartPolicy 7.3.1.1.2.13. FERestartPolicy
FE restart policy - This specifies the behavior of the FE during an FE restart policy - This specifies the behavior of the FE during an
FE restart. The restart may be from an FE failure or other reasons FE restart. The restart may be from an FE failure or other reasons
that have made FE down and then need to restart. The values are that have made the FE down and then need to restart. The values are
defined as below: defined as follows:
o 0(default)- Restart the FE from scratch. In this case, the FE o 0(default)- Restart the FE from scratch. In this case, the FE
should start from the pre-association phase. should start from the pre-association phase.
o others - Reserved for future use. o Others - Reserved for future use.
7.3.2. FE Object LFB 7.3.2. FE Object LFB
The FE Object LFB is a logical entity in each FE and contains The FE Object LFB is a logical entity in each FE and contains
attributes relative to the FE itself, and not to the operation of the components relative to the FE itself, and not to the operation of the
ForCES protocol. ForCES protocol.
The formal definition of the FE Object LFB can be found in The formal definition of the FE Object LFB can be found in [RFC5812].
[FE-MODEL]. The model captures the high level properties of the FE The model captures the high-level properties of the FE that the CE
that the CE needs to know to begin working with the FE. The class ID needs to know to begin working with the FE. The class ID for this
for this LFB Class is also assigned in [FE-MODEL]. The singular LFB class is also assigned in [RFC5812]. The singular instance of
instance of this class will always exist, and will always have this class will always exist, and will always have instance ID 0x1
instance ID 0x1 within its class. It is common, although not within its class. It is common, although not mandatory, for a CE to
mandatory, for a CE to fetch much of the component and capability fetch much of the component and capability information from this LFB
information from this LFB instance when the CE begins controlling the instance when the CE begins controlling the operation of the FE.
operation of the FE.
7.4. Semantics of Message Direction 7.4. Semantics of Message Direction
Recall: The PL provides a master(CE)-Slave(FE) relationship. The Recall: The PL provides a master(CE)-slave(FE) relationship. The
LFBs reside at the FE and are controlled by CE. LFBs reside at the FE and are controlled by CE.
When messages go from the CE, the LFB Selector (Class and instance) When messages go from the CE, the LFB selector (class and instance)
refers to the destination LFB selection which resides in the FE. refers to the destination LFB selection that resides in the FE.
When messages go from the FE to the CE, the LFB Selector (Class and When messages go from the FE to the CE, the LFB selector (class and
instance) refers to the source LFB selection which resides in the FE. instance) refers to the source LFB selection that resides in the FE.
7.5. Association Messages 7.5. Association Messages
The ForCES Association messages are used to establish and teardown The ForCES Association messages are used to establish and tear down
associations between FEs and CEs. associations between FEs and CEs.
7.5.1. Association Setup Message 7.5.1. Association Setup Message
This message is sent by the FE to the CE to setup a ForCES This message is sent by the FE to the CE to set up a ForCES
association between them. association between them.
Message transfer direction: Message transfer direction:
FE to CE FE to CE
Message header: Message header:
The Message Type in the header is set MessageType= The Message Type in the header is set to MessageType=
'AssociationSetup'. The ACK flag in the header MUST be ignored, 'AssociationSetup'. The ACK flag in the header MUST be ignored,
and the association setup message always expects to get a response and the Association Setup message always expects to get a response
from the message receiver (CE), whether the setup is successful or from the message receiver (CE), whether or not the setup is
not. The correlator field in the header is set, so that FE can successful. The correlator field in the header is set, so that FE
correlate the response coming back from the CE correctly. The FE can correlate the response coming back from the CE correctly. The
may set the source ID to 0 in the header to request that the CE FE may set the source ID to 0 in the header to request that the CE
should assign an FE ID for the FE in the setup response message. should assign an FE ID for the FE in the Setup Response message.
Message body: Message body:
The association setup message body optionally consists of zero, The Association Setup message body optionally consists of zero,
one or two LFBselect TLVs, as described in Section 7.1.5. The one, or two LFBselect TLVs, as described in Section 7.1.5. The
Association Setup message only operates on the FE Object and FE Association Setup message only operates on the FE Object and FE
Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV Protocol LFBs; therefore, the LFB class ID in the LFBselect TLV
only points to these two kinds of LFBs. only points to these two kinds of LFBs.
The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' The OPER-TLV in the LFBselect TLV is defined as a 'REPORT'
operation. More than one component may be announced in this operation. More than one component may be announced in this
message using REPORT operation to let the FE declare its message using the REPORT operation to let the FE declare its
configuration parameters in an unsolicited manner. These may configuration parameters in an unsolicited manner. These may
contain components suggesting values such as the FE HB Interval, contain components suggesting values such as the FE HB Interval or
or the FEID. The OPER-TLV used is defined below. the FEID. The OPER-TLV used is defined below.
OPER-TLV for Association Setup: OPER-TLV for Association Setup:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: OPER-TLV Figure 23: OPER-TLV
Type: Type:
Only one operation type is defined for the association setup Only one operation type is defined for the Association Setup
message: message:
Type = "REPORT" - this type of operation is for FE to Type = "REPORT" - This type of operation is for the FE to report
report something to CE. something to the CE.
PATH-DATA-TLV for REPORT: PATH-DATA-TLV for REPORT:
This is generically a PATH-DATA-TLV format that has been defined This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA BNF definition. The PATH- in Section 7 in the PATH-DATA BNF definition. The PATH-DATA-TLV
DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but for the REPORT operation MAY contain FULLDATA-TLV(s) but SHALL NOT
SHALL NOT contain any RESULT-TLV in the data format. The RESULT- contain any RESULT-TLV in the data format. The RESULT-TLV is
TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in defined in Section 7.1.7 and the FULLDATA-TLV is defined in
Section 7.1.8. Section 7.1.8.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = Association Setup) main hdr (type = Association Setup)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = FE object | +-- LFBCLASSID = FE object
| | | |
| | | |
| +-- LFBInstance = 0x1 | +-- LFBInstance = 0x1
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
| |
| +---OPER-TLV = REPORT
+-- LFBInstance = 0x1 |
| +-- Path-data to one or more components
+---OPER-TLV = REPORT
|
+-- Path-data to one or more components
Figure 23: PDU Format For Association Setup Message Figure 24: PDU Format for Association Setup Message
7.5.2. Association Setup Response Message 7.5.2. Association Setup Response Message
This message is sent by the CE to the FE in response to the Setup This message is sent by the CE to the FE in response to the Setup
message. It indicates to the FE whether the setup is successful or message. It indicates to the FE whether or not the setup is
not, i.e., whether an association is established. successful, i.e., whether an association is established.
Message transfer direction: Message transfer direction:
CE to FE
Message Header: CE to FE
The Message Type in the header is set MessageType=
'AssociationSetupResponse'. The ACK flag in the header MUST be Message header:
ignored, and the setup response message never expects to get any
more responses from the message receiver (FE). The destination The Message Type in the header is set to MessageType=
ID in the header will be set to the source ID in the 'AssociationSetupResponse'. The ACK flag in the header MUST be
corresponding association setup message, unless that source ID ignored, and the Setup Response message never expects to get any more
was 0. If the corresponding source ID was 0, then the CE will responses from the message receiver (FE). The destination ID in the
assign an FE ID value and use that value for the destination ID. header will be set to the source ID in the corresponding Association
Setup message, unless that source ID was 0. If the corresponding
source ID was 0, then the CE will assign an FE ID value and use that
value for the destination ID.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASRresult | Length | | Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Setup Result | | Association Setup Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: ASResult OPER-TLV Figure 25: ASResult OPER-TLV
Type (16 bits): Type (16 bits):
The type of the TLV is "ASResult".
The type of the TLV is "ASResult".
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in octets.
Association Setup Result (32 bits): Length of the TLV including the T and L fields, in octets.
This indicates whether the setup msg was successful or whether
the FE request was rejected by the CE. the defined values are:
0 = success Association Setup result (32 bits):
1 = FE ID invalid This indicates whether the Setup message was successful or whether
the FE request was rejected by the CE. The defined values are:
2 = permission denied 0 = success
1 = FE ID invalid
2 = permission denied
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = Association Setup Response) main hdr (type = Association Setup Response)
| |
| |
+--- T = ASResult-TLV +--- T = ASResult-TLV
Figure 25: PDU Format for Association Setup Repsonse Message Figure 26: PDU Format for Association Setup Response Message
7.5.3. Association Teardown Message 7.5.3. Association Teardown Message
This message can be sent by the FE or CE to any ForCES element to end This message can be sent by the FE or CE to any ForCES element to end
its ForCES association with that element. its ForCES association with that element.
Message transfer direction: Message transfer direction:
CE to FE, or FE to CE (or CE to CE)
CE to FE, or FE to CE (or CE to CE)
Message Header: Message Header:
The Message Type in the header is set MessageType=
"AssociationTeardown". The ACK flag MUST be ignored. The The Message Type in the header is set to MessageType=
correlator field in the header MUST be set to zero and MUST be "AssociationTeardown". The ACK flag MUST be ignored. The correlator
ignored by the receiver. field in the header MUST be set to zero and MUST be ignored by the
receiver.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ASTreason | Length | | Type = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason | | Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: ASTreason-TLV Figure 27: ASTreason-TLV
Type (16 bits): Type (16 bits):
The type of the TLV is "ASTreason".
The type of the TLV is "ASTreason".
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in octets.
Teardown Reason (32 bits): Length of the TLV including the T and L fields, in octets.
This indicates the reason why the association is being
terminated. Several reason codes are defined as follows.
0 - normal teardown by administrator Teardown reason (32 bits):
1 - error - loss of heartbeats This indicates the reason why the association is being terminated.
Several reason codes are defined as follows.
2 - error - out of bandwidth 0 - normal teardown by administrator
3 - error - out of memory 1 - error - loss of heartbeats
4 - error - application crash 2 - error - out of bandwidth
255 - error - other or unspecified 3 - error - out of memory
4 - error - application crash
255 - error - other or unspecified
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = Association Teardown) main hdr (type = Association Teardown)
| |
| |
+--- T = ASTreason-TLV +--- T = ASTreason-TLV
Figure 27: PDU Format for Association Teardown Message Figure 28: PDU Format for Association Teardown Message
7.6. Configuration Messages 7.6. Configuration Messages
The ForCES Configuration messages are used by CE to configure the FEs The ForCES Configuration messages are used by CE to configure the FEs
in a ForCES NE and report the results back to the CE. in a ForCES NE and report the results back to the CE.
7.6.1. Config Message 7.6.1. Config Message
This message is sent by the CE to the FE to configure LFB components This message is sent by the CE to the FE to configure LFB components
in the FE. This message is also used by the CE to subscribe/ in the FE. This message is also used by the CE to subscribe/
unsubscribe to LFB events. unsubscribe to LFB events.
As usual, a config message is composed of a common header followed by As usual, a Config message is composed of a common header followed by
a message body that consists of one or more TLV data format. a message body that consists of one or more TLV data formats.
Detailed description of the message is as below. Detailed description of the message is as follows:
Message transfer direction: Message transfer direction:
CE to FE
Message Header: CE to FE
The Message Type in the header is set MessageType= 'Config'. The
ACK flag in the header can be set to any value defined in Message header:
Section 6.1, to indicate whether or not a response from FE is
expected by the message. The Message Type in the header is set to MessageType= 'Config'. The
ACK flag in the header can be set to any value defined in
Section 6.1, to indicate whether or not a response from the FE is
expected by the message.
OPER-TLV for Config: OPER-TLV for Config:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: OPER-TLV for Config Figure 29: OPER-TLV for Config
Type: Type:
The operation type for config message. two types of operations
for the config message are defined:
Type = "SET" - this operation is to set LFB components The operation type for Config message. Two types of operations for
the Config message are defined:
Type = "SET-PROP" - this operation is to set LFB component Type = "SET" - This operation is to set LFB components
properties
Type = "DEL" - this operation to delete some LFB
components
Type = "COMMIT" - this operation is sent to the FE to Type = "SET-PROP" - This operation is to set LFB component
commit in a 2pc transaction. A COMMIT TLV is an empty TLV properties.
i.e it has no "V"alue. In other words, There is a Length
of 4 (which is for the header only).
Type = "TRCOMP" - this operation is sent to the FE to mark Type = "DEL" - This operation is to delete some LFB components.
the success from an NE perspective of a 2pc transaction.
A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In Type = "COMMIT" - This operation is sent to the FE to commit in a
other words, There is a Length of 4 (which is for the 2pc transaction. A COMMIT TLV is an empty TLV, i.e., it
has no "V"alue. In other words, there is a length of 4
(which is for the header only).
Type = "TRCOMP" - This operation is sent to the FE to mark the
success from an NE perspective of a 2pc transaction. A
TRCOMP TLV is an empty TLV, i.e., it has no "V"alue. In
other words, there is a length of 4 (which is for the
header only). header only).
PATH-DATA-TLV: PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA-TLV BNF definition. The
restriction on the use of PATH-DATA-TLV for SET/SET-PROP
operation is that it MUST contain either a FULLDATA-TLV or
SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The
restriction on the use of PATH-DATA-TLV for DEL operation is it
MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT
contain any RESULT-TLV. The RESULT-TLV is defined in
Section 7.1.7 and FULLDATA-TLV and SPARSEDATA-TLVs is defined in
Section 7.1.8.
*Note: For Event subscription, the events will be defined by the This is generically a PATH-DATA-TLV format that has been defined in
Section 7 in the PATH-DATA-TLV BNF definition. The restriction on
the use of PATH-DATA-TLV for SET/SET-PROP operation is that it MUST
contain either FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT
contain any RESULT-TLV. The restriction on the use of PATH-DATA-TLV
for DEL operation is it MAY contain FULLDATA-TLV or
SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The
RESULT-TLV is defined in Section 7.1.7 and FULLDATA-TLVs and
SPARSEDATA-TLVs are defined in Section 7.1.8.
Note: For Event subscription, the events will be defined by the
individual LFBs. individual LFBs.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = Config) main hdr (type = Config)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
skipping to change at page 74, line 29 skipping to change at page 71, line 35
| // associated with FULLDATA-TLV or SPARSEDATA-TLV(s) | // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
| |
+-- T = operation { DEL } +-- T = operation { DEL }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
. .
. .
Figure 29: PDU Format for Configuration Message Figure 30: PDU Format for Configuration Message
7.6.2. Config Response Message 7.6.2. Config Response Message
This message is sent by the FE to the CE in response to the Config This message is sent by the FE to the CE in response to the Config
message. It indicates whether the Config was successful or not on message. It indicates whether or not the Config was successful on
the FE and also gives a detailed response regarding the configuration the FE and also gives a detailed response regarding the configuration
result of each component. result of each component.
Message transfer direction: Message transfer direction:
FE to CE
Message Header: FE to CE
The Message Type in the header is set MessageType= 'Config Message header:
Response'. The ACK flag in the header is always ignored, and the
Config Response message never expects to get any further response The Message Type in the header is set to MessageType= 'Config
from the message receiver (CE). Response'. The ACK flag in the header is always ignored, and the
Config Response message never expects to get any further response
from the message receiver (CE).
OPER-TLV for Config Response: OPER-TLV for Config Response:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: OPER-TLV for Config Response Figure 31: OPER-TLV for Config Response
Type: Type:
The operation type for Config Response message. Two types of The operation type for Config Response message. Two types of
operations for the Config Response message are defined: operations for the Config Response message are defined:
Type = "SET-RESPONSE" - this operation is for the response Type = "SET-RESPONSE" - This operation is for the response of the
of SET operation of LFB components SET operation of LFB components.
Type = "SET-PROP-RESPONSE" - this operation is for the Type = "SET-PROP-RESPONSE" - This operation is for the response
response of SET-PROP operation of LFB component properties of the SET-PROP operation of LFB component properties.
Type = "DEL-RESPONSE" - this operation is for the response Type = "DEL-RESPONSE" - This operation is for the response of the
of the DELETE operation of LFB components DELETE operation of LFB components.
Type = "COMMIT-RESPONSE" - this operation is sent to the Type = "COMMIT-RESPONSE" - This operation is sent to the CE to
CE to confirm a commit success in a 2pc transaction. A confirm a commit success in a 2pc transaction. A
COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating
success or failure. success or failure.
PATH-DATA-TLV: PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA-TLV BNF definition. The This is generically a PATH-DATA-TLV format that has been defined in
restriction on the use of PATH-DATA-TLV for SET-RESPONSE Section 7 in the PATH-DATA-TLV BNF definition. The restriction on
operation is that it MUST contain RESULT-TLV(s). The restriction the use of PATH-DATA-TLV for SET-RESPONSE operation is that it MUST
on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV
MUST contain RESULT-TLV(s). The RESULT-TLV is defined in for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s).
Section 7.1.7. The RESULT-TLV is defined in Section 7.1.7.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = ConfigResponse) main hdr (type = ConfigResponse)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
skipping to change at page 76, line 29 skipping to change at page 73, line 32
| // associated with FULL or SPARSEDATA-TLV(s) | // associated with FULL or SPARSEDATA-TLV(s)
| |
+-- T = operation { DEL-RESPONSE } +-- T = operation { DEL-RESPONSE }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { COMMIT-RESPONSE } +-- T = operation { COMMIT-RESPONSE }
| | | |
| +-- RESULT-TLV | +-- RESULT-TLV
Figure 31: PDU Format for Configuration Response message Figure 32: PDU Format for Config Response Message
7.7. Query Messages 7.7. Query Messages
The ForCES query messages are used by the CE to query LFBs in the FE The ForCES Query messages are used by the CE to query LFBs in the FE
for information like LFB components, capabilities, statistics, etc. for information like LFB components, capabilities, statistics, etc.
Query Messages include the Query Message and the Query Response Query messages include the Query message and the Query Response
Message. message.
7.7.1. Query Message 7.7.1. Query Message
A Query message is composed of a common header and a message body A Query message is composed of a common header and a message body
that consists of one or more TLV data format. Detailed description that consists of one or more TLV data formats. Detailed description
of the message is as below. of the message is as follows:
Message transfer direction: Message transfer direction:
from CE to FE
Message Header: from CE to FE
The Message Type in the header is set to MessageType= 'Query'. Message header:
The ACK flag in the header is always ignored, and a full response
for a query message is always expected. The Correlator field in The Message Type in the header is set to MessageType= 'Query'. The
the header is set, so that the CE can locate the response back ACK flag in the header is always ignored, and a full response for a
from FE correctly. Query message is always expected. The Correlator field in the header
is set, so that the CE can locate the response back from FE
correctly.
OPER-TLV for Query: OPER-TLV for Query:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET/GET-PROP | Length | | Type = GET/GET-PROP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP | | PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: TLV for Query Figure 33: TLV for Query
Type: Type:
The operation type for query. Two operation types are defined:
Type = "GET" - this operation is to request to get LFB The operation type for query. Two operation types are defined:
Type = "GET" - This operation is to request to get LFB
components. components.
Type = "GET-PROP" - this operation is to request to get Type = "GET-PROP" - This operation is to request to get LFB
LFB components. component properties.
PATH-DATA-TLV for GET/GET-PROP: PATH-DATA-TLV for GET/GET-PROP:
This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA-TLV BNF definition. The This is generically a PATH-DATA-TLV format that has been defined in
restriction on the use of PATH-DATA-TLV for GET/GET-PROP Section 7 in the PATH-DATA-TLV BNF definition. The restriction on
operation is it MUST NOT contain any SPARSEDATA-TLV or FULLDATA- the use of PATH-DATA-TLV for GET/GET-PROP operation is it MUST NOT
TLV and RESULT-TLV in the data format. contain any SPARSEDATA-TLV or FULLDATA- TLV and RESULT-TLV in the
data format.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = Query) main hdr (type = Query)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
skipping to change at page 78, line 25 skipping to change at page 75, line 28
| |
+-- T = operation { GET } +-- T = operation { GET }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { GET } +-- T = operation { GET }
. | . |
. +-- // one or more path targets . +-- // one or more path targets
. .
Figure 33: PDU Format for Query Message Figure 34: PDU Format for Query Message
7.7.2. Query Response Message 7.7.2. Query Response Message
When receiving a Query message, the receiver should process the When receiving a Query message, the receiver should process the
message and come up with a query result. The receiver sends the message and come up with a query result. The receiver sends the
query result back to the message sender by use of the Query Response query result back to the message sender by use of the Query Response
Message. The query result can be the information being queried if message. The query result can be the information being queried if
the query operation is successful, or can also be error codes if the the query operation is successful, or can also be error codes if the
query operation fails, indicating the reasons for the failure. query operation fails, indicating the reasons for the failure.
A Query Response message is also composed of a common header and a A Query Response message is also composed of a common header and a
message body consisting of one or more TLVs describing the query message body consisting of one or more TLVs describing the query
result. Detailed description of the message is as below. result. Detailed description of the message is as follows:
Message transfer direction: Message transfer direction:
from FE to CE
Message Header: from FE to CE
The Message Type in the header is set to MessageType=
'QueryResponse'. The ACK flag in the header is ignored. As a Message header:
response itself, the message does not expect a further response.
The Message Type in the header is set to MessageType=
'QueryResponse'. The ACK flag in the header is ignored. As a
response itself, the message does not expect a further response.
OPER-TLV for Query Response: OPER-TLV for Query Response:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: TLV for Query Response Figure 35: TLV for Query Response
Type: Type:
The operation type for query response. One operation type is
defined:
Type = "GET-RESPONSE" - this operation is to response to The operation type for query response. One operation type is
get operation of LFB components. defined:
Type = "GET-PROP-RESPONSE" - this operation is to response Type = "GET-RESPONSE" - This operation is for the response of the
to GET-PROP operation of LFB components. GET operation of LFB components.
Type = "GET-PROP-RESPONSE" - This operation is for the response
of the GET-PROP operation of LFB components.
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA-TLV BNF definition. The This is generically a PATH-DATA-TLV format that has been defined in
PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA- Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV
TLV, FULLDATA-TLV and/or RESULT-TLV(s) in the data encoding. The for the GET-RESPONSE operation MAY contain SPARSEDATA-TLV,
RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs FULLDATA-TLV, and/or RESULT-TLV(s) in the data encoding. The
and FULLDATA-TLVs are defined in Section 7.1.8. RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs and
FULLDATA-TLVs are defined in Section 7.1.8.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = QueryResponse) main hdr (type = QueryResponse)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
skipping to change at page 80, line 25 skipping to change at page 77, line 28
| |
+-- T = operation { GET-RESPONSE } +-- T = operation { GET-RESPONSE }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { GET-PROP-RESPONSE } +-- T = operation { GET-PROP-RESPONSE }
. | . |
. +-- // one or more path targets . +-- // one or more path targets
. .
Figure 35: PDU Format for Query Response Message Figure 36: PDU Format for Query Response Message
7.8. Event Notification Message 7.8. Event Notification Message
Event Notification Message is used by FE to asynchronously notify CE Event Notification message is used by the FE to asynchronously notify
of events that happen in the FE. the CE of events that happen in the FE.
All events that can be generated in an FE are subscribable by the CE. All events that can be generated in an FE are subscribable by the CE.
The CE can subscribe to an event via a Config message with SET-PROP The CE can subscribe to an event via a Config message with the SET-
operation, where the included path specifies the event, as defined by PROP operation, where the included path specifies the event, as
the LFB Library and described by the FE Model. defined by the LFB Library and described by the FE Model.
As usual, an Event Notification Message is composed of a common As usual, an Event Notification message is composed of a common
header and a message body that consists of one or more TLV data header and a message body that consists of one or more TLV data
format. Detailed description of the message is as below. formats. Detailed description of the message is as follows:
Message Transfer Direction: Message transfer direction:
FE to CE
Message Header: FE to CE
The Message Type in the message header is set to Message header:
MessageType = 'EventNotification'. The ACK flag in the header
MUST be ignored by the CE, and the event notification message does The Message Type in the message header is set to
not expect any response from the receiver. MessageType = 'EventNotification'. The ACK flag in the header MUST
be ignored by the CE, and the Event Notification message does not
expect any response from the receiver.
OPER-TLV for Event Notification: OPER-TLV for Event Notification:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: TLV for Event Notification Figure 37: TLV for Event Notification
Type: Type:
Only one operation type is defined for the event notification
message:
Type = "REPORT" - this type of operation is for FE to Only one operation type is defined for the Event Notification
report something to CE. message:
Type = "REPORT" - This type of operation is for the FE to report
something to the CE.
PATH-DATA-TLV for REPORT: PATH-DATA-TLV for REPORT:
This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA-TLV BNF definition. The This is generically a PATH-DATA-TLV format that has been defined in
PATH-DATA-TLV for REPORT operation MAY contain FULLDATA-TLV or Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV
SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data for the REPORT operation MAY contain FULLDATA-TLV or
format. SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data
format.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = Event Notification) main hdr (type = Event Notification)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = target LFB class +-- LFBCLASSID = target LFB class
skipping to change at page 82, line 25 skipping to change at page 79, line 28
| |
+-- T = operation { REPORT } +-- T = operation { REPORT }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| // associated with FULL/SPARSE DATA TLV(s) | // associated with FULL/SPARSE DATA TLV(s)
+-- T = operation { REPORT } +-- T = operation { REPORT }
. | . |
. +-- // one or more path targets . +-- // one or more path targets
. // associated with FULL/SPARSE DATA TLV(s) . // associated with FULL/SPARSE DATA TLV(s)
Figure 37: PDU Format for Event Notification Message Figure 38: PDU Format for Event Notification Message
7.9. Packet Redirect Message 7.9. Packet Redirect Message
A packet Redirect message is used to transfer data packets between CE A Packet Redirect message is used to transfer data packets between
and FE. Usually these data packets are control packets but they may the CE and FE. Usually, these data packets are control packets, but
be just data-path packets which need further (exception or high- they may be just data path packets that need further (exception or
touch) processing. It is also feasible that this message carries no high-touch) processing. It is also feasible that this message
data packets and rather just metadata. carries no data packets and rather just meta data.
The Packet Redirect message data format is formatted as follows: The Packet Redirect message data format is formatted as follows:
Message Direction: Message transfer direction:
CE to FE or FE to CE
Message Header: CE to FE or FE to CE
The Message Type in the header is set to MessageType=
'PacketRedirect'.
Message Body: Message header:
This consists of one or more TLVs that contain or describe the
packet being redirected. The TLV is specifically a Redirect TLV The Message Type in the header is set to MessageType=
(with the TLV Type="Redirect"). Detailed data format of a 'PacketRedirect'.
Redirect TLV for packet redirect message is as below:
Message body:
This consists of one or more TLVs that contain or describe the packet
being redirected. The TLV is specifically a Redirect TLV (with the
TLV Type="Redirect"). Detailed data format of a Redirect TLV for a
Packet Redirect message is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Redirect | Length | | Type = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV | | Meta Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV | | Redirect Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: Redirect_Data TLV Figure 39: Redirect_Data TLV
Meta Data TLV: Meta Data TLV:
This is a TLV that specifies meta-data associated with followed
redirected data. The TLV is as follows: This is a TLV that specifies meta data associated with followed
redirected data. The TLV is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = METADATA-TLV | Length | | Type = METADATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: METADATA-TLV Figure 40: METADATA-TLV
Meta Data ILV: Meta Data ILV:
This is an Identifier-Length-Value format that is used to describe
one meta data. The ILV has the format as: This is an Identifier-Length-Value format that is used to describe
one meta data. The ILV has the format as:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID | | Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value | | Meta Data Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: Meta Data ILV Figure 41: Meta Data ILV
Where, Meta Data ID is an identifier for the meta data, which is where Meta Data ID is an identifier for the meta data, which is
statically assigned by the LFB definition. statically assigned by the LFB definition.
Redirect Data TLV Redirect Data TLV:
This is a TLV describing one packet of data to be directed via the
redirect operation. The TLV format is as follows: This is a TLV describing one packet of data to be directed via the
redirect operation. The TLV format is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REDIRECTDATA-TLV | Length | | Type = REDIRECTDATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data | | Redirected Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Redirect Data TLV Figure 42: Redirect Data TLV
Redirected Data: Redirected Data:
This field contains the packet that is to be redirected in network
byte order. The packet should be 32-bits aligned as is the data This field contains the packet that is to be redirected in network
for all TLVs. The metadata infers what kind of packet is carried byte order. The packet should be 32 bits aligned as is the data for
in value field and therefore allows for easy decoding of data all TLVs. The meta data infers what kind of packet is carried in
encapsulated value field and therefore allows for easy decoding of data
encapsulated.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
main hdr (type = PacketRedirect) main hdr (type = PacketRedirect)
| |
| |
+--- T = Redirect +--- T = Redirect
. | . |
. +-- T = METADATA-TLV . +-- T = METADATA-TLV
skipping to change at page 85, line 22 skipping to change at page 82, line 25
| +-- Meta Data ILV | +-- Meta Data ILV
| | | |
| +-- Meta Data ILV | +-- Meta Data ILV
| . | .
| . | .
| |
+-- T = REDIRECTDATA-TLV +-- T = REDIRECTDATA-TLV
| |
+-- // Redirected Data +-- // Redirected Data
Figure 42: PDU Format for Packet Redirect Message Figure 43: PDU Format for Packet Redirect Message
7.10. Heartbeat Message 7.10. Heartbeat Message
The Heartbeat (HB) Message is used for one ForCES element (FE or CE) The Heartbeat (HB) message is used for one ForCES element (FE or CE)
to asynchronously notify one or more other ForCES elements in the to asynchronously notify one or more other ForCES elements in the
same ForCES NE on its liveness. Section 4.3.3 describes the traffic- same ForCES NE on its liveness. Section 4.3.3 describes the traffic-
sensitive approach used. sensitive approach used.
A Heartbeat Message is sent by a ForCES element periodically. The A Heartbeat message is sent by a ForCES element periodically. The
parameterization and policy definition for heartbeats for an FE is parameterization and policy definition for heartbeats for an FE are
managed as components of the FE Protocol Object LFB, and can be set managed as components of the FE Protocol Object LFB, and can be set
by CE via a Config message. The Heartbeat message is a little by CE via a Config message. The Heartbeat message is a little
different from other protocol messages in that it is only composed of different from other protocol messages in that it is only composed of
a common header, with the message body left empty. A detailed a common header, with the message body left empty. A detailed
description of the message is as below. description of the message is as follows:
Message Transfer Direction: Message transfer direction:
FE to CE or CE to FE
Message Header: FE to CE or CE to FE
The Message Type in the message header is set to MessageType =
'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. Message header:
The ACK flag in the header MUST be set to either 'NoACK' or
'AlwaysACK' when the HB is sent. The Message Type in the message header is set to MessageType =
'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. The
ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK'
when the HB is sent.
* When set to 'NoACK', the HB is not soliciting for a response. * When set to 'NoACK', the HB is not soliciting for a response.
* When set to 'AlwaysACK', the HB Message sender is always * When set to 'AlwaysACK', the HB Message sender is always
expecting a response from its receiver. According the HB expecting a response from its receiver. According to the HB
policies defined in Section 7.3.1, only the CE can send such policies defined in Section 7.3.1, only the CE can send such
an HB message to query FE liveness. For simplicity and an HB message to query FE liveness. For simplicity and
because of the minimal nature of the HB message, the response because of the minimal nature of the HB message, the response
to a HB message is another HB message, i.e., no specific HB to an HB message is another HB message, i.e., no specific HB
response message is defined. Whenever an FE receives a HB Response message is defined. Whenever an FE receives an HB
message marked with 'AlwaysACK' from the CE, the FE MUST send message marked with 'AlwaysACK' from the CE, the FE MUST send
a HB message back immediately. The HB message sent by the FE an HB message back immediately. The HB message sent by the
in response to the 'AlwasyACK' MUST modify the source and FE in response to the 'AlwaysACK' MUST modify the source and
destination IDs so that the ID of the FE is the source ID and destination IDs so that the ID of the FE is the source ID and
the CE ID of the sender is the destination ID, and MUST the CE ID of the sender is the destination ID, and MUST
change the ACK information to 'NoACK'. A CE MUST NOT respond change the ACK information to 'NoACK'. A CE MUST NOT respond
to an HB message with 'AlwasyACK' set. to an HB message with 'AlwaysACK' set.
* When set to anything else other than 'NoACK' or 'AlwaysACK', * When set to anything else other than 'NoACK' or 'AlwaysACK',
the HB Message is treated as if it was a 'NoACK'. the HB message is treated as if it was a 'NoACK'.
The correlator field in the HB message header SHOULD be set The correlator field in the HB message header SHOULD be set
accordingly when a response is expected so that a receiver can accordingly when a response is expected so that a receiver can
correlate the response correctly. The correlator field MAY be correlate the response correctly. The correlator field MAY be
ignored if no response is expected. ignored if no response is expected.
Message Body: Message body:
The message body is empty for the Heartbeat Message.
The message body is empty for the Heartbeat message.
8. High Availability Support 8. High Availability Support
The ForCES protocol provides mechanisms for CE redundancy and The ForCES protocol provides mechanisms for CE redundancy and
failover, in order to support High Availability as defined in failover, in order to support High Availability as defined in
[RFC3654]. FE redundancy and FE to FE interaction is currently out [RFC3654]. FE redundancy and FE to FE interaction is currently out
of scope of this document. There can be multiple redundant CEs and of scope of this document. There can be multiple redundant CEs and
FEs in a ForCES NE. However, at any one time only one primary CE can FEs in a ForCES NE. However, at any one time only one primary CE can
control the FEs though there can be multiple secondary CEs. The FE control the FEs though there can be multiple secondary CEs. The FE
and the CE PL are aware of the primary and secondary CEs. This and the CE PL are aware of the primary and secondary CEs. This
information (primary, secondary CEs) is configured in the FE and in information (primary, secondary CEs) is configured in the FE and in
the CE PLs during pre-association by the FEM and the CEM the CE PLs during pre-association by the FEM and the CEM
respectively. Only the primary CE sends control messages to the FEs. respectively. Only the primary CE sends control messages to the FEs.
8.1. Relation with the FE Protocol 8.1. Relation with the FE Protocol
High Availability parameterization in an FE is driven by configuring High Availability parameterization in an FE is driven by configuring
the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1).
The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
Heartbeat policy help in detecting connectivity problems between an Heartbeat policy help in detecting connectivity problems between an
FE and CE. The CE Failover policy defines the reaction on a detected FE and CE. The CE failover policy defines the reaction on a detected
failure. failure.
Figure 43 extends the state machine illustrated in Figure 4 to allow Figure 44 extends the state machine illustrated in Figure 4 to allow
for new states that facilitate connection recovery. for new states that facilitate connection recovery.
(CE issues Teardown || +-----------------+ (CE issues Teardown || +-----------------+
Lost association) && | Pre-Association | Lost association) && | Pre-association |
CE failover policy = 0 | (Association | CE failover policy = 0 | (Association |
+------------>-->-->| in +<----+ +------------>-->-->| in +<----+
| | progress) | | | | progress) | |
| CE Issues +--------+--------+ | | CE issues +--------+--------+ |
| Association | | CFTI | Association | | CFTI
| Setup V | timer | Setup V | timer
| ___________________+ | expires | ___________________+ | expires
| | | | | |
| V ^ | V ^
+-+-----------+ +-------+-----+ +-+-----------+ +-------+-----+
| | | Not | | | | Not |
| | (CE issues Teardown || | Associated | | | (CE issues Teardown || | Associated |
| | Lost association) && | | | | Lost association) && | |
| Associated | CE Failover Policy = 1 | (May | | Associated | CE failover policy = 1 | (May |
| | | Continue | | | | Continue |
| |---------->------->------>| Forwarding)| | |---------->------->------>| Forwarding)|
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
^ V ^ V
| | | |
| CE Issues | | CE issues |
| Association | | Association |
| Setup | | Setup |
+_________________________________________+ +_________________________________________+
Figure 43: FE State Machine considering HA Figure 44: FE State Machine Considering HA
Section 4.2 describes transitions between the Pre-association, Section 4.2 describes transitions between the pre-association,
associated and not associated states. associated, and not associated states.
When communication fails between the FE and CE (which can be caused When communication fails between the FE and CE (which can be caused
by either the CE or link failure but not FE related), either the TML by either the CE or link failure but not FE related), either the TML
on the FE will trigger the FE PL regarding this failure or it will be on the FE will trigger the FE PL regarding this failure or it will be
detected using the HB messages between FEs and CEs. The detected using the HB messages between FEs and CEs. The
communication failure, regardless of how it is detected, MUST be communication failure, regardless of how it is detected, MUST be
considered as a loss of association between the CE and corresponding considered as a loss of association between the CE and corresponding
FE. FE.
If the FE's FEPO CE Failover Policy is configured to mode 0 (the If the FE's FEPO CE failover policy is configured to mode 0 (the
default), it will immediately transition to the pre-association default), it will immediately transition to the pre-association
phase. This means that if association is again established, all FE phase. This means that if association is again established, all FE
state will need to be re-established. state will need to be re-established.
If the FE's FEPO CE Failover Policy is configured to mode 1, it If the FE's FEPO CE failover policy is configured to mode 1, it
indicates that the FE is capable of HA restart recovery. In such a indicates that the FE is capable of HA restart recovery. In such a
case, the FE transitions to the not associated state and the CEFTI case, the FE transitions to the not associated state and the CEFTI
timer is started. The FE MAY continue to forward packets during this timer is started. The FE MAY continue to forward packets during this
state. It MAY also recycle through any configured secondary CEs in a state. It MAY also recycle through any configured secondary CEs in a
round-robin fashion. It first adds its primary CE to the tail of round-robin fashion. It first adds its primary CE to the tail of
backup CEs and sets its primary CE to be the first secondary. It backup CEs and sets its primary CE to be the first secondary. It
then attempts to associate with the CE designated as the new primary then attempts to associate with the CE designated as the new primary
CE. If it fails to re-associate with any CE and the CEFTI expires, CE. If it fails to re-associate with any CE and the CEFTI expires,
the FE then transitions to the pre-association state. the FE then transitions to the pre-association state.
If the FE, while in the not associated state, manages to reconnect to If the FE, while in the not associated state, manages to reconnect to
a new primary CE before CEFTI expires it transitions to the a new primary CE before CEFTI expires, it transitions to the
Associated state. Once re-associated, the FE tries to recover any associated state. Once re-associated, the FE tries to recover any
state that may have been lost during the not associated state. How state that may have been lost during the not associated state. How
the FE achieves re-synchronizes it state is out of scope for this the FE achieves this is out of scope for this document.
document.
Figure 44 below illustrates the Forces message sequences that the FE Figure 45 below illustrates the ForCES message sequences that the FE
uses to recover the connection. uses to recover the connection.
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| All msgs | | | All msgs | |
2 |<--------------------->| | 2 |<--------------------->| |
| | | | | |
skipping to change at page 89, line 43 skipping to change at page 85, line 50
| | | |
| Asso Estb,Caps exchange | | Asso Estb,Caps exchange |
3 |<------------------------------------------>| 3 |<------------------------------------------>|
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
4 |------------------------------------------->| 4 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
5 |<------------------------------------------>| 5 |<------------------------------------------>|
Figure 44: CE Failover for Report Primary Mode Figure 45: CE Failover for Report Primary Mode
A CE-to-CE synchronization protocol would be needed to support fast A CE-to-CE synchronization protocol would be needed to support fast
failover as well as to address some of the corner cases, however this failover as well as to address some of the corner cases; however,
will not be defined by the ForCES protocol as it is out of scope for this will not be defined by the ForCES protocol as it is out of scope
this specification. for this specification.
An explicit message (a Config message setting Primary CE component in An explicit message (a Config message setting primary CE component in
ForCES Protocol object) from the primary CE, can also be used to the FE Protocol Object) from the primary CE can also be used to
change the Primary CE for an FE during normal protocol operation. change the primary CE for an FE during normal protocol operation.
Also note that the FEs in a ForCES NE could also use a multicast CE Also note that the FEs in a ForCES NE could also use a multicast CE
ID, i.e., they could be associated with a group of CEs (this assumes ID, i.e., they could be associated with a group of CEs (this assumes
the use of a CE-CE synchronization protocol, which is out of scope the use of a CE-CE synchronization protocol, which is out of scope
for this specification). In this case, the loss of association would for this specification). In this case, the loss of association would
mean that communication with the entire multicast group of CEs has mean that communication with the entire multicast group of CEs has
been lost. The mechanisms described above will apply for this case been lost. The mechanisms described above will apply for this case
as well during the loss of association. If, however, the secondary as well during the loss of association. If, however, the secondary
CE was also using the multicast CE ID that was lost, then the FE will CE was also using the multicast CE ID that was lost, then the FE will
need to form a new association using a different CE ID. If the need to form a new association using a different CE ID. If the
capability exists, the FE MAY first attempt to form a new association capability exists, the FE MAY first attempt to form a new association
with original primary CE using a different non multicast CE ID. with the original primary CE using a different non-multicast CE ID.
8.2. Responsibilities for HA 8.2. Responsibilities for HA
TML Level: TML level:
1. The TML controls logical connection availability and failover. 1. The TML controls logical connection availability and failover.
2. The TML also controls peer HA management. 2. The TML also controls peer HA management.
At this level, control of all lower layers, for example transport At this level, control of all lower layers, for example, transport
level (such as IP addresses, MAC addresses etc) and associated links level (such as IP addresses, MAC addresses, etc.) and associated
going down are the role of the TML. links going down are the role of the TML.
PL level:
PL Level:
All other functionality, including configuring the HA behavior during All other functionality, including configuring the HA behavior during
setup, the CE IDs used to identify primary and secondary CEs, setup, the CE IDs used to identify primary and secondary CEs,
protocol messages used to report CE failure (Event Report), Heartbeat protocol messages used to report CE failure (Event Report), Heartbeat
messages used to detect association failure, messages to change the messages used to detect association failure, messages to change the
primary CE (Config), and other HA related operations described primary CE (Config), and other HA-related operations described
before, are the PL responsibility. before, are the PL responsibility.
To put the two together, if a path to a primary CE is down, the TML To put the two together, if a path to a primary CE is down, the TML
would take care of failing over to a backup path, if one is would take care of failing over to a backup path, if one is
available. If the CE is totally unreachable then the PL would be available. If the CE is totally unreachable, then the PL would be
informed and it would take the appropriate actions described before. informed and it would take the appropriate actions described earlier.
9. Security Considerations 9. Security Considerations
ForCES Framework document [RFC3746], section 8 goes into extensive The ForCES framework document [RFC3746], Section 8, goes into
detail on a variety of security threats, the possible effects of extensive detail on a variety of security threats, the possible
those threats on the protocol and responses to those threats. This effects of those threats on the protocol, and responses to those
document does not repeat that discussion, the reader is referred to threats. This document does not repeat that discussion; the reader
the ForCES Framework document [RFC3746] for those details and how the is referred to the ForCES framework document [RFC3746] for those
ForCES architecture addresses them. details and how the ForCES architecture addresses them.
ForCES PL uses security services provided by the ForCES TML. The TML ForCES PL uses security services provided by the ForCES TML. The TML
provides security services such as endpoint authentication service, provides security services such as endpoint authentication service,
message authentication service and confidentiality service. Endpoint message authentication service, and confidentiality service.
authentication service is invoked at the time of the pre-association Endpoint authentication service is invoked at the time of the pre-
connection establishment phase and message authentication is association connection establishment phase and message authentication
performed whenever the FE or CE receives a packet from its peer. is performed whenever the FE or CE receives a packet from its peer.
The following are the general security mechanisms that need to be in The following are the general security mechanisms that need to be in
place for ForCES PL. place for ForCES PL.
o Security mechanisms are session controlled - that is, once the o Security mechanisms are session controlled -- that is, once the
security is turned on depending upon the chosen security level (No security is turned on depending upon the chosen security level (No
Security, Authentication, Confidentiality), it will be in effect Security, Authentication, Confidentiality), it will be in effect
for the entire duration of the session. for the entire duration of the session.
o An operator should configure the same security policies for both o An operator should configure the same security policies for both
primary and backup FEs and CEs (if available). This will ensure primary and backup FEs and CEs (if available). This will ensure
uniform operations and avoid unnecessary complexity in policy uniform operations and avoid unnecessary complexity in policy
configuration. configuration.
9.1. No Security 9.1. No Security
When "No security" is chosen for ForCES protocol communication, both When "No Security" is chosen for ForCES protocol communication, both
endpoint authentication and message authentication service needs to endpoint authentication and message authentication service needs to
be performed by ForCES PL. Both these mechanism are weak and do not be performed by ForCES PL. Both these mechanism are weak and do not
involve cryptographic operation. An operator can choose "No involve cryptographic operation. An operator can choose "No
Security" level when the ForCES protocol endpoints are within a Security" level when the ForCES protocol endpoints are within a
single box, for example. single box, for example.
In order to have interoperable and uniform implementation across In order to have interoperable and uniform implementation across
various security levels, each CE and FE endpoint MUST implement this various security levels, each CE and FE endpoint MUST implement this
level. level.
What is described below (in Section 9.1.1 and Section 9.1.2) are What is described below (in Section 9.1.1 and Section 9.1.2) are
error checks and not security procedures. The reader is referred to error checks and not security procedures. The reader is referred to
section Section 9.2. for security procedures. Section 9.2 for security procedures.
9.1.1. Endpoint Authentication 9.1.1. Endpoint Authentication
Each CE and FE PL maintains a list of associations as part its of Each CE and FE PL maintains a list of associations as part of its
configuration. This is done via the CEM and FEM interfaces. An FE configuration. This is done via the CEM and FEM interfaces. An FE
MUST connect to only those CEs that are configured via the FEM; MUST connect to only those CEs that are configured via the FEM;
similarly, a CE should accept the connection and establish similarly, a CE should accept the connection and establish
associations for the FEs which are configured via the CEM. The CE associations for the FEs which are configured via the CEM. The CE
should validate the FE identifier before accepting the connections should validate the FE identifier before accepting the connections
during the pre-association phase. during the pre-association phase.
9.1.2. Message Authentication 9.1.2. Message Authentication
When a CE or FE initiates a message, the receiving endpoint MUST When a CE or FE initiates a message, the receiving endpoint MUST
validate the initiator of the message by checking the common header validate the initiator of the message by checking the common header
CE or FE identifiers. This will ensure proper protocol functioning. CE or FE identifiers. This will ensure proper protocol functioning.
This extra processing step is recommended even when the underlying This extra processing step is recommended even when the underlying
TML layer security services exist. TML layer security services exist.
9.2. ForCES PL and TML security service 9.2. ForCES PL and TML Security Service
This section is applicable if an operator wishes to use the TML This section is applicable if an operator wishes to use the TML
security services. A ForCES TML MUST support one or more security security services. A ForCES TML MUST support one or more security
services such as endpoint authentication service, message services such as endpoint authentication service, message
authentication service, and confidentiality service, as part of TML authentication service, and confidentiality service, as part of TML
security layer functions. It is the responsibility of the operator security layer functions. It is the responsibility of the operator
to select an appropriate security service and configure security to select an appropriate security service and configure security
policies accordingly. The details of such configuration are outside policies accordingly. The details of such configuration are outside
the scope of the ForCES PL and are dependent on the type of transport the scope of the ForCES PL and are dependent on the type of transport
protocol and the nature of the connection. protocol and the nature of the connection.
All these configurations should be done prior to starting the CE and All these configurations should be done prior to starting the CE and
FE. FE.
When certificates-based authentication is being used at the TML, the When certificates-based authentication is being used at the TML, the
certificate can use a ForCES-specific naming structure as certificate certificate can use a ForCES-specific naming structure as certificate
names and, accordingly, the security policies can be configured at names and, accordingly, the security policies can be configured at
the CE and FE. the CE and FE.
The reader is asked to refer to specific TML documents for details on The reader is asked to refer to specific TML documents for details on
the security requirements specific to that TML the security requirements specific to that TML.
9.2.1. Endpoint authentication service 9.2.1. Endpoint Authentication Service
When TML security services are enabled, the ForCES TML performs When TML security services are enabled, the ForCES TML performs
endpoint authentication. Security association is established between endpoint authentication. Security association is established between
CE and FE and is transparent to the ForCES PL. CE and FE and is transparent to the ForCES PL.
9.2.2. Message authentication service 9.2.2. Message Authentication Service
This is a TML specific operation and is transparent to the ForCES PL. This is a TML-specific operation and is transparent to the ForCES PL.
For details, refer to Section 5. For details, refer to Section 5.
9.2.3. Confidentiality service 9.2.3. Confidentiality Service
This is a TML specific operation and is transparent to the ForCES PL. This is a TML-specific operation and is transparent to the ForCES PL.
For details, refer to Section 5. For details, refer to Section 5.
10. Acknowledgements 10. Acknowledgments
The authors of this draft would like to acknowledge and thank the The authors of this document would like to acknowledge and thank the
ForCES Working Group and especially the following: Furquan Ansari, ForCES Working Group and especially the following: Furquan Ansari,
Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M.
Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Zsolt
Halpern (who should probably be listed among the authors), Zsolt
Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering,
T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their
contributions. We would also like to thank David Putzolu, and contributions. We would also like to thank David Putzolu and Patrick
Patrick Droz for their comments and suggestions on the protocol and Droz for their comments and suggestions on the protocol and for their
for their infinite patience. We would also like to thank Sue Hares infinite patience. We would also like to thank Sue Hares and Alia
and Alia Atlas for extensive reviews of the document. Atlas for extensive reviews of the document.
Alia Atlas has done a wonderful job of shaping the draft to make it Alia Atlas did a wonderful job of shaping the document to make it
more readable by providing the IESG feedback. more readable by providing the IESG feedback.
Ross Callon was instrumental in getting us over major humps to
getting this document published.
The editors have used the xml2rfc [RFC2629] tools in creating this The editors have used the xml2rfc [RFC2629] tools in creating this
document and are very grateful for the existence and quality of these document and are very grateful for the existence and quality of these
tools. The editor is also grateful to Elwyn Davies for his help in tools. The editor is also grateful to Elwyn Davies for his help in
correcting the XML source of this document. correcting the XML source of this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FE-MODEL]
Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,
and S. Blake, "ForCES Forwarding Element Model",
Feb. 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in [RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008. the Session Initiation Protocol", RFC 5390, December 2008.
[SCTP-TML] [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Hadi Salim, J. and K. Ogawa, "SCTP based TML (Transport Layer (TML) for the Forwarding and Control Element
Mapping Layer) for ForCES protocol", internet Separation (ForCES) Protocol", RFC 5811, March 2010.
draft draft-ietf-forces-sctptml, work in progress,
Feb. 2009.
11.2. Informational References [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.
[2PCREF] Gray, J., "Notes on database operating systems. In 11.2. Informative References
Operating Systems: An Advanced Course. Lecture Notes in
Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", [2PCREF] Gray, J., "Notes on database operating systems", in
"Operating Systems: An Advanced Course" Lecture Notes in
Computer Science, Vol. 60, pp. 394-481, Springer-Verlag,
1978. 1978.
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction- [ACID] Haerder, T. and A. Reuter, "Principles of Transaction-
Orientated Database Recovery", 1983. Orientated Database Recovery", 1983.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003. of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
Appendix A. IANA Considerations Appendix A. IANA Considerations
Following the policies outlined in "Guidelines for Writing an IANA Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following
name spaces are defined in ForCES. namespaces are defined in ForCES.
o Message Type Name Space Section 7 o Message Type Namespace, Section 7
o Operation Type Name Space Section 7.1.6 o Operation Type Namespace, Section 7.1.6
o Header Flags Section 6.1 o Header Flags, Section 6.1
o TLV Type Section 7 o TLV Type, Section 7
o TLV Result Values Section 7.1.7 o TLV Result Values, Section 7.1.7
o LFB Class ID Section 7.1.5 o LFB Class ID, Section 7.1.5 (resolved by model document,
[RFC5812].
o Result: Association Setup Response Section 7.5.2 o Result: Association Setup Response, Section 7.5.2
o Reason: Association Teardown Message Section 7.5.3 o Reason: Association Teardown Message, Section 7.5.3
A.1. Message Type Name Space A.1. Message Type Namespace
The Message Type is an 8 bit value. The following is the guideline The Message Type is an 8-bit value. The following is the guideline
for defining the Message Type namespace for defining the Message Type namespace:
Message Types 0x00 - 0x0F Message Types 0x00 - 0x1F
Message Types in this range are part of the base ForCES Protocol. Message Types in this range are part of the base ForCES protocol.
Message Types in this range are allocated through an IETF Message Types in this range are allocated through an IETF
consensus action. [RFC5226] consensus action [RFC5226].
Values assigned by this specification: Values assigned by this specification:
0x00 Reserved 0x00 Reserved
0x01 AssociationSetup 0x01 AssociationSetup
0x02 AssociationTeardown 0x02 AssociationTeardown
0x03 Config 0x03 Config
0x04 Query 0x04 Query
0x05 EventNotification 0x05 EventNotification
0x06 PacketRedirect 0x06 PacketRedirect
0x07 - 0x0E Reserved 0x07 - 0x0E Reserved
0x0F Hearbeat 0x0F Hearbeat
0x11 AssociationSetupRepsonse 0x11 AssociationSetupResponse
0x12 Reserved 0x12 Reserved
0x13 ConfigRepsonse 0x13 ConfigResponse
0x14 QueryResponse 0x14 QueryResponse
Message Types 0x20 - 0x7F Message Types 0x20 - 0x7F
Message Types in this range are Specification Required [RFC5226] Message Types in this range are Specification Required [RFC5226].
Message Types using this range MUST be documented in an RFC or Message Types using this range MUST be documented in an RFC or
other permanent and readily available reference. other permanent and readily available reference.
Message Types 0x80 - 0xFF Message Types 0x80 - 0xFF
Message Types in this range are reserved for vendor private Message Types in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA extensions and are the responsibility of individual vendors. IANA
management of this range of the Message Type Name Space is management of th