draft-ietf-forces-protocol-08.txt   draft-ietf-forces-protocol-09.txt 
Network Working Group A. Doria (Ed.) Network Working Group A. Doria (Ed.)
Internet-Draft ETRI Internet-Draft ETRI
Expires: September 24, 2006 R. Haas (Ed.) Intended status: Standards Track R. Haas (Ed.)
IBM Expires: August 5, 2007 IBM
J. Hadi Salim (Ed.) J. Hadi Salim (Ed.)
Znyx Znyx
H. Khosravi (Ed.) H. Khosravi (Ed.)
Intel Intel
W. M. Wang (Ed.) W. M. Wang (Ed.)
Zhejiang Gongshang University Zhejiang Gongshang University
March 23, 2006
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-08.txt draft-ietf-forces-protocol-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 24, 2006. This Internet-Draft will expire on August 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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. 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 RFC3654. Besides
the ForCES protocol messages, the specification also defines the the ForCES protocol messages, the specification also defines the
framework, the mechanisms, and the Transport Mapping Layer (TML) framework, the mechanisms, and the Transport Mapping Layer (TML)
requirements for ForCES protocol. requirements for ForCES protocol.
Authors Authors
The participants in the ForCES Protocol Team, primary co-authors and The participants in the ForCES Protocol Team, primary co-authors and
co-editors, of this protocol specification, are: co-editors, of this protocol specification, are:
Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea
Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M University of Technology), Ram Gopal (Nokia), Robert Haas (IBM),
Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang
(Zhejiang Gongshang University).
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12
4.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 13 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 14 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18
4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 19 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20
4.3.1. Transactions, Atomicity, Execution and Responses . . 19 4.3.1. Transactions, Atomicity, Execution and Responses . . 20
4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 23 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 24
4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 23 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 25
4.3.4. FE Object and FE protocol LFBs . . . . . . . . . . . 24 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 25
5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 25 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 25
5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 26 4.4.1. Association Setup State . . . . . . . . . . . . . . . 26
6. Message encapsulation . . . . . . . . . . . . . . . . . . . . 27 4.4.2. Association Established state or Steady State . . . . 27
6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 27 4.4.3. Transaction messaging . . . . . . . . . . . . . . . . 29
6.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 32 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 31
6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 32 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 32
6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 32 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 33
6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 33
7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 34 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 38
7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 34 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 39
7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 34 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 39
7.1.2. Protocol Visualization . . . . . . . . . . . . . . . 43 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 46 6.4. Important Protocol encapsulations . . . . . . . . . . . . 40
7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 47 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 50 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 41
7.3. Semantics of message Direction . . . . . . . . . . . . . 50 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Association Messages . . . . . . . . . . . . . . . . . . 50 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 41
7.4.1. Association Setup Message . . . . . . . . . . . . . . 50 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 43
7.4.2. Association Setup Response Message . . . . . . . . . 52 7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 43
7.4.3. Association Teardown Message . . . . . . . . . . . . 53 7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 43
7.5. Configuration Messages . . . . . . . . . . . . . . . . . 54 7.1.2. Protocol Encoding Visualization . . . . . . . . . . . 58
7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 54 7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 61
7.5.2. Config Response Message . . . . . . . . . . . . . . . 56 7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 62
7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 57 7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 65
7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 58 7.3. Semantics of Message Direction . . . . . . . . . . . . . 65
7.6.2. Query Response Message . . . . . . . . . . . . . . . 59 7.4. Association Messages . . . . . . . . . . . . . . . . . . 66
7.7. Event Notification Message . . . . . . . . . . . . . . . 60 7.4.1. Association Setup Message . . . . . . . . . . . . . . 66
7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 62 7.4.2. Association Setup Response Message . . . . . . . . . 68
7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 65 7.4.3. Association Teardown Message . . . . . . . . . . . . 69
7.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 66 7.5. Configuration Messages . . . . . . . . . . . . . . . . . 70
8. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 69 7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 70
8.1. Association Setup state . . . . . . . . . . . . . . . . . 69 7.5.2. Config Response Message . . . . . . . . . . . . . . . 72
8.2. Association Established state or Steady State . . . . . . 70 7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 73
9. High Availability Support . . . . . . . . . . . . . . . . . . 73 7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 74
9.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 75 7.6.2. Query Response Message . . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 7.7. Event Notification Message . . . . . . . . . . . . . . . 76
10.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 77 7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 78
10.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 77 7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 80
10.1.2. Message authentication . . . . . . . . . . . . . . . 78 8. High Availability Support . . . . . . . . . . . . . . . . . . 82
10.2. ForCES PL and TML security service . . . . . . . . . . . 78 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 82
10.2.1. Endpoint authentication service . . . . . . . . . . . 78 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 85
10.2.2. Message authentication service . . . . . . . . . . . 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 87
10.2.3. Confidentiality service . . . . . . . . . . . . . . . 79 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 87
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 87
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 9.1.2. Message authentication . . . . . . . . . . . . . . . 88
12.1. Normative References . . . . . . . . . . . . . . . . . . 81 9.2. ForCES PL and TML security service . . . . . . . . . . . 88
12.2. Informational References . . . . . . . . . . . . . . . . 81 9.2.1. Endpoint authentication service . . . . . . . . . . . 88
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 82 9.2.2. Message authentication service . . . . . . . . . . . 88
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 82 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 88
A.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 90
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 84 11.2. Informational References . . . . . . . . . . . . . . . . 90
A.6. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 85 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 91
A.7. Association Setup Response . . . . . . . . . . . . . . . 86 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 91
A.8. Association Teardown Message . . . . . . . . . . . . . . 86 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 92
A.9. Configuration Request Result . . . . . . . . . . . . . . 87 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 93
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 88 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 93
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 93 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 93
B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 93 A.6. Association Setup Response . . . . . . . . . . . . . . . 94
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 94 A.7. Association Teardown Message . . . . . . . . . . . . . . 95
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 98 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 96
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 101
Intellectual Property and Copyright Statements . . . . . . . . . 116 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 102
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 103
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123
Intellectual Property and Copyright Statements . . . . . . . . . 125
1. Terminology and Conventions 1. Terminology and Conventions
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC 2119 [RFC2119]. as described in BCP 14, RFC 2119 [RFC2119].
2. Introduction 2. 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 3764 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 term "ForCES protocol" and
"protocol" as used in this document refers to the protocol used to "protocol" as used in this document refers 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. ForCES FE model [FE-MODEL] and Forwarding Elements (FEs) only.
presents the capabilities, state and configuration of FEs within the
context of the ForCES protocol, so that CEs can accordingly control The ForCES FE model [FE-MODEL] presents a formal way to define FE
the FEs in a standardizded way and by means of the ForCES protocol. Logical Function Blocks (LFBs) using XML. LFB configuration
attributes, capabilities, and associated events are defined when the
LFB is formally created. The LFBs within the FE are accordingly
controlled in a standardized way by the ForCES protocol.
This document defines the ForCES protocol specifications. The ForCES 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. Information exchanged between FEs and CEs makes are masters. The protocol includes commands for transport of Logical
extensive use of TLVs. The protocol includes commands for transport Function Block(LFB) configuration information, association setup,
of LFB configuration information, association setup, status and event status, and event notifications, etc.
notifications, etc.
This specification does not define a transport mechanism for protocol This specification does not define a transport mechanism for protocol
messages, but does include a discussion of service primitives that messages. A discussion of service primitives that must be provided
must be provided by the underlying transport interface. by the underlying transport interface will be discussed in a future
document.
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 discussion Section 4 provides an overview of the protocol, including a
on the protocol framework, descriptions of the Protocol Layer (PL) discussion on the protocol framework, descriptions of the Protocol
and a Transport Mapping Layer (TML), as well as of the ForCES Layer (PL) and a Transport Mapping Layer (TML), as well as of the
protocol mechanisms. ForCES protocol mechanisms. Section 4.4 describes several Protocol
scenarios and includes message exchange descriptions.
While this document does not define the TML, Section 5 details the 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 several Protocol Scenarios and includes message Section 8 describes the protocol support for high availability
exchange descriptions. mechanisms including redundancy and fail over.
Section 9 describes a mechanism in the protocol to support high Section 9 defines the security mechanisms provided by the PL and TML.
availability mechanisms including redundancy and fail over.
Section 10 defines the security mechanisms provided by the PL and
TML.
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 below are repeated below for clarity.
Addressable Entity (AE) - A physical device that is directly Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on IP addressable given some interconnect technology. For example, on IP
networks, it is a device which can be reached using an IP address; 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 and on a switch fabric, it is a device which can be reached using a
switch fabric port number. switch fabric port number.
Forwarding Element (FE) - A logical entity that implements the ForCES
protocol. FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by a CE via the ForCES
protocol.
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of control packets. CEs handle functionality such as the execution of control
and signaling protocols. and signaling protocols.
Pre-association Phase - The period of time during which an FE Manager CE Manager (CEM) - A logical entity responsible for generic CE
(see below) and a CE Manager (see below) are determining which FE(s) management tasks. It is particularly used during the pre-association
and CE(s) should be part of the same network element. 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.
Post-association Phase - The period of time during which an FE knows Datapath - A conceptual path taken by packets within the forwarding
which CE is to control it and vice versa. This includes the time plane inside an FE.
during which the CE and FE are establishing communication with one
another. Forwarding Element (FE) - A logical entity that implements the ForCES
protocol. FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by one or more CEs via
the ForCES protocol.
FE Model - A model that describes the logical processing functions of FE Model - A model that describes the logical processing functions of
an FE. an FE.
FE Manager (FEM) - A logical entity responsible for generic FE FE Manager (FEM) - A logical entity responsible for generic FE
management tasks. It is used during pre-association phase to management tasks. It is used during pre-association phase to
determine with which CE(s) an FE should communicate. This process is determine with which CE(s) an FE should communicate. This process is
called CE discovery and may involve the FE manager learning the called CE discovery and may involve the FE manager learning the
capabilities of available CEs. An FE manager may use anything from a capabilities of available CEs. An FE manager may use anything from a
static configuration to a pre-association phase protocol (see below) static configuration to a pre-association phase protocol (see below)
to determine which CE(s) to use. Being a logical entity, an FE to determine which CE(s) to use. Being a logical entity, an FE
manager might be physically combined with any of the other logical manager might be physically combined with any of the other logical
entities such as FEs. entities such as FEs.
CE Manager (CEM) - A logical entity responsible for generic CE
management tasks. It is particularly used during the pre-association
phase to determine with which FE(s) a CE should communicate. This
process is called FE discovery and may involve the CE manager
learning the capabilities of available FEs.
ForCES Network Element (NE) - An entity composed of one or more CEs ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside a NE, the NE represents a and one or more FEs. To entities outside an NE, the NE represents a
single point of management. Similarly, a NE usually hides its single point of management. Similarly, an NE usually hides its
internal organization from external entities. internal organization from external entities.
High Touch Capability - This term will be used to apply to the High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents 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 or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT, the IP header. Examples of these capabilities include NAT-PT,
firewall, and L7 content recognition. firewall, and L7 content recognition.
Datapath -- A conceptual path taken by packets within the forwarding Inter-FE Topology - See FE Topology.
plane inside an FE.
LFB (Logical Function Block) -- The basic building block that is Intra-FE Topology - See LFB Topology.
LFB (Logical Function Block) - The basic building block that is
operated on by the ForCES protocol. The LFB is a well defined, operated on by the ForCES protocol. The LFB is a well defined,
logically separable functional block that resides in an FE and is logically separable functional block that resides in an FE and is
controlled by the CE via ForCES protocol. The LFB may reside at the 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 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 configuration entity that is operated on by the CE. Note that the
LFB is a functionally accurate abstraction of the FE's processing LFB is a functionally accurate abstraction of the FE's processing
capabilities, but not a hardware-accurate representation of the FE capabilities, but not a hardware-accurate representation of the FE
implementation. implementation.
LFB (Logical Function Block) and LFB Instance -- LFBs are categorized FE Topology - A representation of how the multiple FEs within a
by LFB Classes(or Types). An LFB Instance represents an LFB Class single NE are interconnected. Sometimes this is called inter-FE
(or Type) existence. There may be multiple instances of the same LFB topology, to be distinguished from intra-FE topology (i.e., LFB
Class (or Type) in an FE. An LFB Class is represented by an LFB topology).
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 specify an LFB existence.
LFB Metadata -- Metadata is used to communicate per-packet state from LFB (Logical Function Block) 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 Metadata - Metadata is used to communicate per-packet state from
one LFB to another, but is not sent across the network. The FE model 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 defines how such metadata is identified, produced and consumed by the
LFBs. It defines the functionality but not how metadata is encoded LFBs. It defines the functionality but not how metadata is encoded
within an implementation. within an implementation.
LFB Attribute -- Operational parameters of the LFBs that must be LFB Attribute - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB visible to the CEs are conceptualized in the FE model as the LFB
attributes. The LFB attributes include, for example, flags, single attributes. The LFB attributes include, for example, flags, single
parameter arguments, complex arguments, and tables that the CE can parameter arguments, complex arguments, and tables that the CE can
read or/and write via the ForCES protocol (see below). read and/or write via the ForCES protocol (see below).
LFB Topology -- Representation of how the LFB instances are logically LFB Topology - Representation of how the LFB instances are logically
interconnected and placed along the datapath within one FE. interconnected and placed along the datapath within one FE.
Sometimes it is also called intra-FE topology, to be distinguished Sometimes it is also called intra-FE topology, to be distinguished
from inter-FE topology. from inter-FE topology.
FE Topology -- A representation of how the multiple FEs within a Pre-association Phase - The period of time during which an FE Manager
single NE are interconnected. Sometimes this is called inter-FE (see below) and a CE Manager (see below) are determining which FE(s)
topology, to be distinguished from intra-FE topology (i.e., LFB and CE(s) should be part of the same network element.
topology).
Inter-FE Topology -- See FE Topology.
Intra-FE Topology -- See LFB Topology. 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 ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" and the overall ForCES architecture, the term "ForCES protocol" and
"protocol" refer to the Fp reference point in the ForCES Framework in "protocol" refer to the Fp reference point in the ForCES Framework in
[RFC3746]. This protocol does not apply to CE-to-CE communication, [RFC3746]. This protocol does not apply to CE-to-CE communication,
FE-to-FE communication, or to communication between FE and CE FE-to-FE communication, or to communication between FE and CE
managers. Basically, the ForCES protocol works in a master-slave managers. Basically, the ForCES protocol works in a master-slave
mode in which FEs are slaves and CEs are masters. This document mode in which FEs are slaves and CEs are masters. This document
defines the specifications for this ForCES protocol. defines the specifications for this ForCES protocol.
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) - A layer in ForCES protocol
architecture that defines the ForCES protocol messages, the protocol architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML (see below)). itself (including requirements of ForCES TML (see below).
Specifications of ForCES PL are defined by this document. Specifications of ForCES PL are defined by this document.
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
ForCES protocol architecture that uses the capabilities of existing ForCES protocol architecture that uses the capabilities of existing
transport protocols to specifically address protocol message 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. order to provide clarity. This document is authoritative on the
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 a 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 | |
skipping to change at page 12, line 4 skipping to change at page 13, line 5
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 Point. The The ForCES protocol domain is found in the Fp Reference Point. 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
is out of scope of the ForCES protocol but is touched on in this in [RFC3746] ) is out of scope of the ForCES protocol but is touched
document in discussion of FEM and CEM since it is an integral part of on in this document in discussion of FEM and CEM since it is an
the protocol pre-association phase. integral part of the protocol pre-association phase.
Figure 2 below shows further breakdown of the Fp interface by example Figure 2 below shows further breakdown of the Fp interface by example
of an MPLS QoS enabled Network Element. 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 12, line 37 skipping to change at page 13, line 38
| 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
layer and the TML layer. and the TML.
This is depicted in Figure 3 below. This is depicted in Figure 3 below.
+------------------------------------------------ +------------------------------------------------
| CE PL layer | | CE PL |
+------------------------------------------------ +------------------------------------------------
| CE TML layer | | 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 layer | | FE TML |
+------------------------------------------------ +------------------------------------------------
| FE PL layer | | FE PL |
+------------------------------------------------ +------------------------------------------------
Figure 3: ForCES Interface Figure 3: ForCES Interface
The PL layer is in fact the ForCES protocol. Its semantics and The PL is in fact the ForCES protocol. Its semantics and message
message layout are defined in this document. The TML Layer is layout are defined in this document. The TML Layer is necessary to
necessary to connect two ForCES PL layers as shown in Figure 3 above. connect two ForCES PLs as shown in Figure 3 above. The TML is out of
The TML is out of scope for this document but is within scope of scope for this document but is within scope of ForCES. This document
ForCES. This document defines requirements the PL needs the TML to defines requirements the PL needs the TML to meet.
meet.
Both the PL and the TML layers are standardized by the IETF. While Both the PL and the TML are standardized by the IETF. While only one
only one PL layer is defined, different TMLs are expected to be PL is defined, different TMLs are expected to be standardized. To
standardized. To interoperate the TML layer at the CE and FE are interoperate the TML at the CE and FE are expected to conform to the
expected to conform to the same definition. same definition.
On transmit, the PL layer delivers its messages to the TML layer. On transmit, the PL delivers its messages to the TML. The local TML
The TML layer delivers the message to the destination TML layer(s). delivers the message to the destination TML. On receive, the TML
On receive, the TML delivers the message to its destination PL delivers the message to its destination PL.
layer(s).
4.1.1. The PL layer 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 layer is responsible by the IETF as defined in this document. The PL is responsible for
for associating an FE or CE to an NE. It is also responsible for associating an FE or CE to an NE. It is also responsible for tearing
tearing down such associations. An FE uses the PL layer to transmit down such associations. An FE uses the PL to transmit various
various subscribed-to events to the CE PL layer as well as to respond subscribed-to events to the CE PL as well as to respond to various
to various status requests issued from the CE PL. The CE configures status requests issued from the CE PL. The CE configures both the FE
both the FE and associated LFBs' operational parameters using the PL and associated LFBs' operational parameters using the PL. In
layer. In addition the CE may send various requests to the FE to addition the CE may send various requests to the FE to activate or
activate or deactivate it, reconfigure its HA parameterization, deactivate it, reconfigure its HA parameterization, subscribe to
subscribe to specific events etc. More details can be found in specific events etc. More details can be found in Section 7.
Section 7.
4.1.2. The TML layer 4.1.2. The TML
The TML layer transports the PL layer messages. The TML is where the The TML transports the PL messages. The TML is where the issues of
issues of how to achieve transport level reliability, congestion how to achieve transport level reliability, congestion control,
control, multicast, ordering, etc. are handled. It is expected more multicast, ordering, etc. are handled. It is expected that more than
than one TML will be standardized. The various possible TMLs could one TML will be standardized. The various possible TMLs could vary
vary their implementations based on the capabilities of underlying their implementations based on the capabilities of underlying media
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 layers, are out of scope of the configurations of both the PL and TML, are out of scope of the ForCES
ForCES protocol. The best way to think of them are as protocol. The best way to think of them is as configurations/
configurations/parameterizations for the PL and TML before they parameterizations for the PL and TML before they become active (or
become active (or even at runtime based on implementation). In the even at runtime based on implementation). In the simplest case, the
simplest case, the FE or CE read a static configuration file. RFC FE or CE reads a static configuration file. RFC 3746 has a more
3746 has a more detailed descriptions on how the FEM and CEM could be detailed description on how the FEM and CEM could be used. The pre-
used. The pre-association phase, where the CEM and FEM can be used, association phase, where the CEM and FEM can be used, are described
are described briefly in Section 4.2.1. briefly in Section 4.2.1.
An example of typical of things the FEM/CEM could configure would be An example of typical things the FEM/CEM could configure would be TML
TML specific parameterizations such as: 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. Issuing the ID for the FE or CE would also be issued during the b. The ID for the FE or CE (which would also be issued during the
pre-association phase. 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
Example of this 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 or more 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 association phase where the ForCES protocol layer happens, and the association phase where the ForCES protocol
operates to manipulate the parameters of the FEs. operates to manipulate the parameters of the FEs.
FE start CE configures FE assoiated CE configures transition to UP
-------+ +--->---->---->---->------->----+ +---->--->---+ +--->---->---->---->------->----+
| | Y | | | Y
Y | | ^ Y | |
| | Y | | | Y
+------+--+ +--------+ +---+-------+ +------+--+ +--------+
| FE | | FE | |FE Pre- | | FE | | FE |
| DOWN | | UP | |Association| | DOWN | CE configures DOWN | UP |
| State | | State | |Phase | | State +<------<-----<------<-- + State |
| | | | | | | | | |
+---------+ +--------+ +-----------+ +---------+ +--------+
^ Y ^ Y
| | | |
+-<---<------<-----<------<----<---+ +-<---<------<-----<------<----<---------<------+
CE configures or FE loses association FE loses association
Figure 4: The FE State Machine Figure 4: The FE State Machine
The FE can only be in one of two states as indicated above. When the In the mandated case, once associated, the FE can only be in one of
FE is in the DOWN state, it is not forwarding packets. When the FE two states, as indicated above. When the FE is in the DOWN state, it
is in the UP state it may be forwarding packets depending on the is not forwarding packets. When the FE is in the UP state it may be
configuration of its specific LFBs. forwarding packets, depending on the configuration of its specific
LFBs. The FE MAY also be in other states when it is capable of
graceful restart and high availaibility. The extra transitions are
explained in Section 8 and not discussed here so as to allow us to
explain the basics with more clarity.
CE configures FE states transitions by means of a so-called FEObject The CE configures FE state transitions by means of the FE Object LFB,
LFB, which is defined in [FE-MODEL] and also explained in Section which is defined in [FE-MODEL] and also explained in Section 7.2.2.
4.3.3 of this document. In FEObject LFB, FE state is defined as an In the FE Object LFB, FE state is defined as an attribute of the LFB,
attribute of the LFB, and CE configuration of the FE state equals CE and CE configuration of the FE state equals CE configuration of this
configuration of this attribute. Note that even in the FE DOWN attribute. Note that even in the FE DOWN state, the FE is
state, the FEObject LFB itself is active. associated.
On start up the FE is in the DOWN state unless it is explicitly The FE stays in the DOWN state until it is explicitly configured by
configured by the CE to transition to the UP state via an FE Object the CE to transition to the UP state via an FE Object admin action.
admin action. This must be done before configuring any other LFBs This must be done before configuring any other LFBs that affect
that affect packet forwarding. packet forwarding. The typical setup will bring up the FE to the UP
state on association.
The FE transitions from the UP state to the DOWN state when it The FE transitions from the UP state to the DOWN state when it
receives a FEObject Admin Down action or when it loses its receives an FEObject Admin Down action. when it loses its association
association with the CE. For the FE to properly complete the with the CE it may go into the pre-association phase depending on the
transition to the DOWN state, it MUST stop Packet forwarding and this programmed policy. For the FE to properly complete the transition to
may impact multiple LFBS. How this is achieved is outside the scope the DOWN state, it MUST stop Packet forwarding and this may impact
of this specification. multiple LFBS. How this is achieved is outside the scope of this
specification.
Note: in the case of loss of association, the FE can also be
configured to not go to the DOWN state.
For the FE to properly complete the transition to the DOWN state it
must stop packet forwarding and that this may affect multiple LFBs.
How 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 read from a In a simple setup, the configuration is static and is read from a
saved configuration file. All the parameters for the association saved configuration file. All the parameters for the association
phase are well known after the pre-association phase is complete. A phase are well known after the pre-association phase is complete. A
protocol such as DHCP may be used to retrieve the configuration protocol such as DHCP may be used to retrieve the configuration
parameters instead of reading them from a static configuration file. parameters instead of reading them from a static configuration file.
Note, this will still be considered static pre-association. Dynamic Note, this will still be considered static pre-association. Dynamic
configuration may also happen using the Fc, Ff and Fl reference configuration may also happen using the Fc, Ff and Fl reference
points. Vendors may use their own proprietary service discovery points (refer to [RFC3746]). Vendors may use their own proprietary
protocol to pass the parameters. Essentially only guidelines are service discovery protocol to pass the parameters. Essentially, only
provided here and the details are left to the implementation. guidelines are provided here and the details are 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
skipping to change at page 17, line 50 skipping to change at page 18, line 31
| | | | | | | |
Figure 6: An example of a message exchange over the Fl reference Figure 6: An 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. phase and may be used to force a disassociation of an FE or CE.
Because the pre-association phase is out of scope, these details are Because the pre-association phase is out of scope, these details are
not discussed any further in this specification. The reader is not discussed any further in this specification. The reader is
referred to the framework document [RFC3746] for a slightly more referred to the framework document [RFC3746] for a slightly more
detailed discussion. 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
o Association Lost Stage
o Association Lost stage 4.2.2.1. Association Setup Stage
4.2.2.1. Association Setup stage
The FE attempts to join the NE. The FE may be rejected or accepted. The FE attempts to join the NE. The FE may be rejected or accepted.
Once granted access into the NE, capabilities exchange happens with Once granted access into the NE, capabilities exchange happens with
the CE querying the FE. Once the CE has the FE capability the CE querying the FE. Once the CE has the FE capability
information, the CE can offer an initial configuration (possibly to information, the CE can offer an initial configuration (possibly to
restore state) and can query certain attributes within either an LFB restore state) and can query certain attributes within either an LFB
or the FE itself. or the FE itself.
More details are provided in Section 8. More details are provided in Section 4.4.
On successful completion of this stage, the FE joins the NE and is On successful completion of this stage, the FE joins the NE and is
moved to the Established State. moved to the Established Stage.
4.2.2.2. Association Established stage 4.2.2.2. Established Stage
In this stage the FE is continuously updated or queried. The FE may In this stage, the FE is continuously updated or queried. The FE may
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 continues until heartbeat notifications if programmed to do so. This stage continues
a termination occurs because of loss of connectivity or is initiated until a termination occurs, either due to loss of connectivity or due
by either the CE or the FE. to a termination initiated by either the CE or the FE.
Refer to section on protocol scenarios, Section 8, for more details. Refer to the section on protocol scenarios, Section 4.4, for more
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 state, both or either the CE or FE declare the other side is
no longer associated. The disconnection could be physically no longer associated. The disconnection could be initiated by either
initiated by either party for administrative purposes but may also be party for administrative purposes but may also be driven by
driven by operational reasons such as loss of connectivity. operational reasons such as loss of connectivity.
It should be noted that loss of connectivity between TMLs is not A core LFB known as FE Protocol Object (FEPO) is defined (refer to
necessarily indicative of loss of association between respective PL Appendix B and Section 7.2.1). FEPO defines various timers which can
layers unless the programmed FE Protocol Object time limit is be used in conjunction with traffic sensitive heartbeat mechanism
exceeded. In other words if the TML repairs the transport loss (Section 4.3.3) to detect loss of connectivity.
before then, the association would still be valid.
When an association is lost between a CE and FE, the FE continues to The loss of connectivity between TMLs does not indicate a loss of
operate as instructed by the CE via the CE failover policy (for association between respective PL layers. If the TML cannot repair
further discussion refer to Section 9 and Appendix B). the transport loss before the programmed FEPO timer thresholds
associated with the FE is exceeded, then the association between the
respective PL layers will be lost.
FEPO defines several policies that can be programmed to define
behavior upon a detected loss of association. The FEPO's programmed
CE failover policy (refer to Section 8, Section 7.2.1, Section 4.3.3
and Appendix B) defines 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 windows. failover as well as command pipelines.
The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP
(Transaction Phase) flag as defined in Common Header Section (Section (Transaction Phase) flag as defined in the Common Header
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
commitment operations. commitment 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 in one protocol operations spanning one or more LFB selectors (refer to
message. The EM flag defined in Common Header Section (Section 6.1) Section 7.1.1.1.5) in one protocol message. The EM flag defined in
selects the execution mode for a protocol message, as below: the Common Header Section 6.1 selects the execution mode for a
protocol message, as below:
a. execute-all-or-none a. execute-all-or-none
b. execute-until-failure b. execute-until-failure
c. continue-execute-on-failure c. continue-execute-on-failure
4.3.1.1.1. execute-all-or-none 4.3.1.1.1. execute-all-or-none
When set to this mode, independent operations in a message targeted When set to this mode of execution, independent operations in a
at one or more LFB selectors will all be executed if no failure message MAY be targeted at one or more LFB selectors within an FE.
occurs for any of the operations. If there is any failure for any of All these operations are executed serially and the FE MUST have no
the operations then none of the operations will be executed, i.e execution failure for any of the operations. If any operation fails
there is roll back for this mode of operation. 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
this mode of operation.
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
commit is issued by the CE.
Care should be taken on how this mode is used because a mis-
configuration could result in traffic losses. To add certainty to
the success of an operation, one should use this mode in a
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 until
the first failure. The rest of the operations are not executed but the first failure. The rest of the operations are not executed but
operations already completed are not undone, i.e. there is no roll operations already completed are not undone. I.e., there is no
back in this mode of operation. 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.
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
details of the FE such as in the case of an FE-CE pair from the same details of the FE such as in the case of an FE-CE pair from the same
vendor where the FE-CE pair is tightly coupled. In such a case, the vendor where the FE-CE pair is tightly coupled. In such a case, the
transactional operations may be simplified further by extra transactional operations may be simplified further by extra
computation at the CE. This view is not discussed further other than computation at the CE. This view is not discussed further other than
to mention that it is not disallowed. to mention that it is not disallowed.
skipping to change at page 21, line 29 skipping to change at page 22, line 32
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 execute 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. transactional operations.
The AT flag and the TP flag in Common Header (Section 6.1) are The AT flag and the TP flag in Common Header (Section 6.1) are
provided for 2PC based transactional operations spanning multiple provided for 2PC-based transactional operations spanning multiple
messages. messages.
The COMMIT operation is specified to be used in the case of a final
commit message.
The AT flag, when set, indicates this message belongs to an Atomic The AT flag, when set, indicates this message belongs to an Atomic
Transaction. All messages for a transaction operation must have the Transaction. All messages for a transaction operation must have the
AT flag set. If not set, it means the message is a stand-alone AT flag set. If not set, it means the message is a stand-alone
message and does not participate in any transaction operation that message and does not participate in any transaction operation that
spans multiple messages. spans multiple messages.
The TP flag indicates the Transaction Phase this message belongs to. The TP flag indicates the Transaction Phase this message belongs to.
There are four (4) possible phases for an transactional operation There are four (4) possible phases for an 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)
A transaction operation is started with a message the TP flag is set A transaction operation is started with a message the TP flag is set
to Start of Transaction (SOT). Multi-part messages, after the first to Start of Transaction (SOT). Multi-part messages, after the first
one, are indicated by the Middle of Transaction flag (MOT). The last one, are indicated by the Middle of Transaction flag (MOT). All
message is indicated by by EOT. messages from the CE MUST set the AlwaysACK flag (Section 6) to
solicit responses from the FE(s).
Before the CE issues a commit (described further below) the FE
only validates that the operation can be executed but does not
execute it.
Any failure notified by the FE causes the CE to execute an Abort Any failure notified by the FE causes the CE to execute an Abort
Transaction (ABT) to all FEs involved in the transaction, rolling Transaction (ABT) to all FEs involved in the transaction, rolling
back all previously executed operations in the transaction. back any previously executed operations in the transaction (There
must be none if a commit has not been issued).
The transaction commitment phase is signaled from the CE to the FE The transaction commitment phase is signaled from the CE to the FE
by an End of Transaction (EOT) configuration message. The FE MUST by an End of Transaction (EOT) configuration message with a COMMIT
respond to the CE's EOT message. If no response is received from operation. The FE MUST respond to the CE's EOT message. If no
the FE within a specified timeout, the transaction MUST be aborted response is received from the FE within a specified timeout, the
by the CE. transaction MUST be aborted by the CE.
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 execute 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 execute 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.
Figure 9 shows an example of how a successful two phase commit
between a CE and an FE would look like.
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 it 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, for sake of simplicity as indicated in In this protocol revision, for sake of simplicity as indicated in
Section 4.2.2.3, an FE losing an association would be required to get Section 4.2.2.3, an FE losing an association would be required to get
entirely new state from the newly associated CE upon a re- entirely new state from the newly associated CE upon a re-
association. The decision on what an FE should do after a lost association. The decision on what an FE should do after a lost
association is dictated by the CE Failover policy (refer to Section 9 association is dictated by the CE Failover policy (refer to Section 8
and Section 7.2). and Section 7.2).
4.3.2. Scalability 4.3.2. Scalability
It is desirable that the PL layer not become the bottleneck when It is desirable that the PL not become the bottleneck when larger
larger bandwidth pipes become available. To pick a hypothetical bandwidth pipes become available. To pick a hypothetical example in
example in today's terms, if a 100Gbps pipe is available and there is today's terms, if a 100Gbps pipe is available and there is sufficient
sufficient work then the PL layer should be able to take advantage of work then the PL should be able to take advantage of this and use all
this and use all of the 100Gbps pipe. Two mechanisms have been of the 100Gbps pipe. Two mechanisms have been provided to achieve
provided to achieve this. The first one is batching and the second this. The first one is batching and the second one is a command
one is a command window. 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, amongst 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 windowing allows for pipelining of independent transactions Command pipelining allows for pipelining of independent transactions
which do not affect each other. Each independent transaction could which 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 o multiple LFB classes and instances (as indicated in the LFB
skipping to change at page 24, line 10 skipping to change at page 25, line 25
Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is Heartbeats (HB) 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.2.1 and Section 7.9 for details. the CE. Refer to Section 7.2.1 and Section 7.9 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, as well as the ForCES protocol itself
must be expressed in terms of this LFB architecture. For this reason must be 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 controls attributes relative to the o FE Object LFB which is used to control attributes relative to the
FE itself. Such attributes include FEState [FE-MODEL], vendor, FE itself. Such attributes include FEState [FE-MODEL], vendor,
etc. etc.
These LFBs are detailed in Section 7.2. These LFBs are detailed in Section 7.2.
4.4. Protocol Scenarios
This section provides a very high level description of sample message
sequences between a CE and FE. For protocol message encoding refer
to Section 6.1 and for the semantics of the protocol refer to
Section 4.3.
4.4.1. Association Setup State
The associations among CEs and FEs are initiated via Association
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
FEs are operating in an insecure environment then the security
associations have to be established between them before any
association messages can be exchanged. The TML will take care of
establishing any security associations.
This is typically followed by capability query, topology query, etc.
When the FE is ready to start forwarding data traffic, it sends an FE
UP Event message to the CE. When the CE is ready, it responds by
enabling the FE by setting the FEStatus to Adminup (Refer to
[FE-MODEL] for details). This indicates to the FE to start
forwarding data traffic. At this point the association establishment
is complete. These sequences of messages are illustrated in the
Figure 7 below.
FE PL CE PL
| |
| Asso Setup Req |
|---------------------->|
| |
| Asso Setup Resp |
|<----------------------|
| |
| LFBx Query capability |
|<----------------------|
| |
| LFBx Query Resp |
|---------------------->|
| |
| FEO Query (Topology) |
|<----------------------|
| |
| FEO Query Resp |
|---------------------->|
| |
| FEO UP Event |
|---------------------->|
| |
| Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->|
| |
Figure 7: Message exchange between CE and FE to establish an NE
association
On successful completion of this state, the FE joins the NE.
4.4.2. Association Established state or Steady State
In this state, the FE is continously updated or queried. The FE may
also send asynchronous event notifications to the CE, synchronous
heartbeat messages, or packet redirect message to the CE. This
continues until a termination (or deactivation) is initiated by
either the CE or FE. Figure 8 below, helps illustrate this state.
FE PL CE PL
| |
| Heart Beat |
|<---------------------------->|
| |
| Heart Beat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Attr |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Attr |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heart Beat |
|<-----------------------------|
. .
. .
| |
Figure 8: Message exchange between CE and FE during steady-state
communication
Note that the sequence of messages shown in the figure serve only as
examples and the message exchange sequences could be different from
what is shown in the figure. Also, note that the protocol scenarios
described in this section do not include all the different message
exchanges that would take place during failover. That is described
in the HA section (Section 8) .
4.4.3. Transaction messaging
This section illustrates the message sequence of a successful 2PC
between one CE and an FE. The case of the multiple FEs is left as an
exercise for the reader
FE PL CE PL
| |
| (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (2) ACKnowledge |
|----------------------------------------------------->|
| |
| (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (4) ACKnowledge |
|----------------------------------------------------->|
| |
| (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc |
|<-----------------------------------------------------|
| |
| (6) ACKnowledge |
|----------------------------------------------------->|
. .
. .
. .
. .
| |
| (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT |
|<-----------------------------------------------------|
| |
| (N+1)Config-response, ACKnowledge, COMMIT-RESPONSE |
|----------------------------------------------------->|
Figure 9: Example of a two phase commit
The flow of for a 2PC message sequence is described with more clarity
in section Section 4.3.1.2.2. For the scenario illustrated above:
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
indicate a Start of Transaction (SOT), Atomic Transaction (AT),
execute-all-or-none.
o The FE validates that it can execute the request successfully and
then issues an acknowledgment back to the the CE in step #2.
o In step #3, the same sort of construct as in step #1 is repeated
by the CE with the transaction flag changed to Middle of
Transaction(MOT).
o The FE validates that it can execute the request successfully and
then issues an acknowledgment back to the the CE in step #4.
o The CE-FE exchange continues in the same manner until all the
operations and their parameters are transferred to the FE. This
happens in step #(N-1).
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
to End of Transaction (EOT). Essentially, this is an "empty"
message asking the FE to execute all the operations it has
gathered since the beginning of the transaction (message #1).
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
contains a COMMIT-RESPONSE.
5. TML Requirements 5. TML Requirements
The requirements below are expected to be delivered by the TML. This The requirements below are expected to be delivered by the TML. This
text does not define how such mechanisms are delivered. As an text does not define how such mechanisms are delivered. As an
example they could be defined to be delivered via hardware or between example they could be defined to be delivered via hardware or between
2 or more TML processes on different CEs or FEs in protocol level 2 or more TML processes on different CEs or FEs in protocol level
schemes. 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.
1. Reliability 1. Reliability
As defined by RFC 3654, section 6 #6. As defined by RFC 3654, section 6 #6.
2. Security 2. Security
TML provides security services to the ForCES PL. TML layer TML provides security services to the ForCES PL. A TML layer
should support the following security services and describe how should support the following security services and describe how
they are achieved. they are achieved.
* Endpoint authentication of FE and CE. * Endpoint authentication of FE and CE
* Message Authentication * Message authentication
* Confidentiality service * Confidentiality service
3. Congestion Control 3. Congestion control
The congestion control scheme used needs to be defined. The The congestion control scheme used needs to be defined. The
congestion control mechanism defined by the TML should prevent congestion control mechanism defined by the TML should prevent
the FE from being overloaded by the CE or the CE from being the FE from being overloaded by the CE or the CE from being
overwhelmed by traffic from the FE. Additionally, the overwhelmed by traffic from the FE. Additionally, the
circumstances under which notification is sent to the PL to circumstances under which notification is sent to the PL to
notify it of congestion must be defined. notify it of congestion must be defined.
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/ If there is any mapping between PL and TML level uni/multi/
Broadcast addressing it needs to be defined. 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, on config basis, the PL layer may wish responsibility. However, based upon its configuration, the PL
to participate in link failover schemes and therefore the TML may wish to participate in link failover schemes and therefore
must support this capability. the TML must support this capability.
Please refer to Section 9 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 layer and will provide priority levels needed by the PL and will provide preferential
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, the 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.
8. Protection against DoS attacks 8. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6 As described in RFC 3654, section 6
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 ports, IP addresses IP/TCP/UDP, then parameters such as TCP and UDP port and IP
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 layer PDUs start with a common header [Section 6.1] followed All PL PDUs start with a common header [Section 6.1] followed by a
by a one or more TLVs [Section 6.2] which may nest other TLVs one or more TLVs [Section 6.2] which may nest other TLVs
[Section 6.2.1]. All fields are in network byte order. [Section 6.2.1]. All 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID | | Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator | | Correlator |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Common Header Figure 10: Common Header
The message is 32 bit aligned. The message is 32 bit aligned.
Version (4 bit): Version (4 bit):
Version number. Current version is 1. Version number. Current version is 1.
rsvd (4 bit): rsvd (4 bit):
Unused at this point. A receiver should not interpret this Unused at this point. A receiver should not interpret this
field. Senders MUST set it to zero and receivers MUST ignore field. Senders MUST set it to zero and receivers MUST ignore
this field. this field.
skipping to change at page 28, line 7 skipping to change at page 34, line 7
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 bit):
Dest ID (32 bit): Dest ID (32 bit):
* Each of the source and Dest IDs are 32 bit IDs which are * Each of the source and destination IDs are 32 bit IDs which
unique NE-wide and which recognize the termination points of are unique NE-wide and which identify the termination points
a ForCES PL message. of a 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. Even though in a large NE there are typically two CEs. Even though in a large NE there are typically two
or more orders of magnitude more FEs than CEs, the or more orders of magnitude more FEs than CEs, the
address space is split uniformly for simplicity. address 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 8: 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 9: 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 be assigned a multicast ID to hide them from the FE. may be assigned a multicast ID to hide them from the FE.
+ Multicast IDs can be used for both source or 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 This field is set by the CE to correlate ForCES Request Messages
with the corresponding Response messages from the FE. with the corresponding Response messages from the FE.
Essentially it is a cookie. The Correlator is handled Essentially it is a cookie. The correlator is handled
transparently by the FE, i.e. for a particular Request message transparently by the FE, i.e., for a particular Request message
the FE MUST assign the same correlator value in the corresponding the FE MUST assign the same correlator value in the corresponding
Response message. In the case where the message from the CE does Response message. In the case where the message from the CE does
not elicit a response, this field may not be useful. not elicit a response, this field may not be useful.
The Correlator field could be used in many implementations The correlator field could be used in many implementations
specific ways by the CE. For example, the CE could split the specific ways by the CE. For example, the CE could split the
Correlator into a 32-bit transactional identifier and 32-bit correlator into a 32-bit transactional identifier and 32-bit
message sequence identifier. Another example a 64 bit pointer to message sequence identifier. Another example is a 64-bit pointer
a context block. All such implementation specific use of the to a context block. All such implementation specific use of the
Correlator is outside the scope of this specification. correlator is outside the scope of this specification.
Whenever the correlator field is not relevant, because no message
is expected, the correlator field is set to 0.
Flags(32 bits): Flags(32 bits):
Identified so far: 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 10: Header Flags Figure 13: Header Flags
- ACK: ACK indicator(2 bit) - ACK: ACK indicator(2 bit)
The ACK indicator flag is only used by the CE when sending a The ACK indicator flag is only used by the CE when sending a
Config Message(Section 7.5.1) or a HB message (Section 7.9) Config Message(Section 7.5.1) or a HB message (Section 7.9)
to indicate to the message receiver whether or not a response to indicate to the message receiver whether or not a response
is required by the sender. Note that for all other messages is required by the sender. Note that for all other messages
than the Config Message or the HB Message this flag MUST be than the Config Message or the HB Message this flag MUST be
ignored. ignored.
The flag values are defined as below: The flag values are defined as below:
'NoACK' (0b00) - to indicate that the message receiver 'NoACK' (0b00) - to indicate that the message receiver
MUST not to send any response message back to this MUST not to send any response message back to this
message sender. message sender.
'SuccessACK'(0b01) - to indicate the message receiver 'SuccessACK'(0b01) - to indicate the message receiver
MUST send a response message back only when the message MUST send a response message back only when the message
has been successfully processed by the receiver. has been successfully processed by the receiver.
'FailureACK'(0b10) - to indicate the message receiver 'FailureACK'(0b10) - to indicate the message receiver
MUST send a response message back only when there is was MUST send a response message back only when there is
failure by the receiver in processing (executing) the failure by the receiver in processing (executing) the
message. In other words, if the message can be processed message. In other words, if the message can be processed
successfully, the sender will not expect any response successfully, the sender will not expect any response
from the receiver. from the receiver.
'AlwaysACK' (0b11) - to indicate the message receiver 'AlwaysACK' (0b11) - to indicate the message receiver
MUST send a response message. MUST send a response message.
Note that in above definitions, the term success implies a Note that in above definitions, the term success implies a
complete execution without any failure of the message. complete execution without any failure of the message.
skipping to change at page 30, line 48 skipping to change at page 37, line 12
summarized below. Detailed descriptions can be found in the summarized below. Detailed descriptions can be found in the
individual message definitions: individual message definitions:
+ Association Setup Message always expects a response. + 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 messages never expect 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). ForCES protocol defines 8 different levels of priority (0-7).
The priority level can be used to distinguish between The priority level can be used to distinguish between
different protocol message types as well as between the same different protocol message types as well as between the same
message type. For example, the REDIRECT PACKET message could message type. The higher the priority value, the more
have different priorities to distinguish between Routing important the PDU is. For example, the REDIRECT packet
protocols packets and ARP packets being redirected from FE to message could have different priorities to distinguish
CE. The Normal priority level is 1. 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) - EM: Execution Mode (2 bits)
There are 3 execution modes refer to Section 4.3.1.1 for There are 3 execution modes refer to Section 4.3.1.1 for
details. details.
Reserved..................... (0b00) Reserved..................... (0b00)
`execute-all-or-none` ....... (0b01) `execute-all-or-none` ....... (0b01)
`execute-until-failure` ..... (0b10) `execute-until-failure` ..... (0b10)
`continue-execute-on-failure` (0b11) `continue-execute-on-failure` (0b11)
- AT Atomic Transaction (1 bit) - AT: Atomic Transaction (1 bit)
This flag indicates if the message is stand-alone message or This flag indicates if the message is stand-alone message or
one of multiple messages that belongs to 2PC transaction one of multiple messages that belongs to 2PC transaction
operations. See Section 4.3.1.2.2 for details. operations. See Section 4.3.1.2.2 for details.
Stand-alone message ......... (0b0) Stand-alone message ......... (0b0)
2PC transaction message ..... (0b1) 2PC transaction message ..... (0b1)
- TP: Transaction Phase (2 bits)
- TP: Transaction phase (2 bits)
A message from the CE to the FE within a transaction could be A message from the CE to the FE within a transaction could be
indicative of the different phases the transaction is in. indicative of the different phases the transaction is in.
Refer to Section 4.3.1.2.2 for details. Refer to Section 4.3.1.2.2 for details.
SOT (start of transaction) ..... (0b00) SOT (start of transaction) ..... (0b00)
MOT (Middle of transaction) .... (0b01) MOT (Middle of transaction) .... (0b01)
EOT (end of transaction) ........(0b10) EOT (end of transaction) ........(0b10)
ABT (abort) .....................(0b11) 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
very nice properties which make them a good candidate for encoding
the XML definitions of the LFB class model. These are:
o Providing for binary type-value encoding that is close to the XML
string tag-value scheme.
o Allowing for fast generalized binary-parsing functions.
o Allowing for forward and backward tag compatibility. This is
equivalent to the XML approach i.e old applications can ignore 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 | variable TLV Length | | TLV Type | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Data of size TLV length) | | Value (Essentially the TLV Data) |
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TLV Representation Figure 14: TLV Representation
TLV Type (16): TLV Type (16):
The TLV type field is two octets, and indicates the The TLV type field is two octets, and semantically
type of data encapsulated within the TLV. indicates the type of data encapsulated within the
TLV.
TLV Length (16): TLV Length (16):
The TLV Length field is two octets, and indicates The TLV length field is two octets, and includes the
the length of this TLV including the TLV Type, TLV length of the TLV type (2 octets), TLV Length (2
Length, and the TLV data in octets. octets), and the length of the TLV data found in the
value field, in octets. Note that this length is
the actual length of the value, before any padding
for alignment is added.
TLV Value (variable): TLV Value (variable):
The TLV Value field carries the data. For The TLV value field carries the data. For
extensibility, the TLV value may in fact be a TLV. extensibility, the TLV value may in fact be a TLV.
TLVs must be 32 bit aligned. Padding is required when the length is not a
multiple of 32 bits, and is the minimum number of
bytes required to bring the TLV to a multiple of 32
bits. The length of the value before padding is
indicated by the TLV Length field. Note: The value
field could be empty which implies the minimal
length a TLV could be is 4 (length of "T" field and
length of "L" 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 an 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 The "Type" values in the TLV are global in scope. This means that
wherever TLVs occur in the PDU, a specific Type value refers to the wherever TLVs occur in the PDU, a specific Type value refers to the
same Type of TLV. This is a design choice that was made to ease same Type of TLV. This is a design choice that was made to ease
debugging of the protocol. debugging of the protocol.
6.3. ILV 6.3. ILV
A slight variation of the TLV known as the ILV. This sets the type A slight variation of the TLV known as the ILV. This sets the type
("T") to be a 32-bit local index that refers to a ForCES element ID. ("T") to be a 32-bit local index that refers to a ForCES element ID.
The Length part of the ILV is fixed at 32 bits. (refer to Section 6.4.1). The Length part of the ILV is fixed at 32
bits.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: 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.1.1.8 for discussions on usage of ILVs. Section 7.1.1.1.8 for discussions on usage of ILVs.
6.4. Important Protocol encapsulations
In this section, we review a few encapsulation concepts that are used
by the ForCES protocol for its operations.
We briefly re-introduce two concepts, Paths and Keys, from the model
draft [FE-MODEL] in order to provide context. The reader is refered
to [FE-MODEL] for a lot of the finer details.
For readability reasons, we introduce the encapsulation schemes that
are used to carry content in a protocol message, namely FULLDATA,
SPARSEDATA, and RESULT TLVs.
6.4.1. Paths
The model draft [FE-MODEL] defines an XML-based language that allows
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
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.
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
given a numeric 32-bit identifier known as an "element id". This
scheme allows the attribute to be "addressed" in a protocol
construct.
These addressable entities could be hierachical (e.g., a table column
or a cell within a table row). In order to address hierachical data,
the concept of a path is introduced by the model [FE-MODEL]. A path
is a series of 32-bit element IDs which are typically presented in a
dot-notation (e.g., 1.2.3.4). The protocol grammar (Section 7.1)
formally defines how paths are used to reference data that is being
encapsulated within a protocol message.
6.4.2. Keys
The model draft [FE-MODEL] defines two ways to address table rows.
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
for content addressing. An example key is a multi-field content key
that uses the IP address and prefix length to uniquely reference an
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
be derived from a key. The KEYINFO TLV (Section 7.1) is used to
carry the data that is used to do the lookup.
6.4.3. DATA TLVs
Data from or to the FE is carried in two types of TLVs: FULLDATA TLV
and SPARSEDATA TLV. Responses on operations executed by the FE are
carried in RESULT TLVs.
In FULLDATA TLV, the data is encoded in such a way that a receiver of
such data, by virtue of being armed with knowledge of the path and
the LFB definition, can infer or correlate the TLV "Value" contents.
This is essentially an optimization that helps reduce the amount of
description required for the transported data in the protocol
grammar. Refer to Appendix C for an example of FULLDATA TLVs.
A number of operations in ForCES will need to reference optional data
within larger structures. The SPARSEDATA TLV encoding is provided to
make it easier to encapsulate optionally appearing data elements.
Refer to Appendix C for an example of SPARSEDATA TLV.
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
Section 7.1.1.1.7 for layout.
6.4.4. Addressing LFB entities
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
an LFB type and instance is selected first. The LFB Selector is used
to select an LFB type and instance being targeted. The protocol
grammar (Section 7.1) goes into more details; for our purpose, we
illustrate this concept using Figure 16 below. More examples of
layouts can be found reading further into the text (Example:
Figure 21).
main hdr (Message type: example "config")
|
|
|
+- T = LFBselect
|
+-- LFBCLASSID (unique per LFB defined)
|
|
+-- LFBInstance (runtime configuration)
|
+-- T = An operation TLV describes what we do to an entity
| //Refer to the OPERSELECT values enumerated below
| //the TLVs that can be used for operations
|
|
+--+-- one or more path encodings to target an entity
| // Refer to the discussion on keys and paths
|
|
+-- The associated data, if any, for the entity
// Refer to discussion on FULL/SPARSE DATA TLVs
Figure 16: Entity Addressing
7. Protocol Construction 7. Protocol Construction
7.1. Protocol Grammar 7.1. Protocol Grammar
The protocol construction is formally defined using a BNF-like syntax The protocol construction is formally defined using a BNF-like syntax
to describe the structure of the PDU layout. This is matched to a to describe the structure of the PDU layout. This is matched to a
precise binary format later in the document. precise binary format later in the document.
Since the protocol is very flexible and hierarchical in nature, it is Since the protocol is very flexible and hierarchical in nature, it is
easier at times to see the visualization layout. This is provided in easier at times to see the visualization layout. This is provided in
Section 7.1.2 Section 7.1.2
7.1.1. Protocol BNF 7.1.1. Protocol BNF
The format used is based on RFC 2234. The terminals of this grammar The format used is based on [RFC2234]. The terminals of this grammar
are flags, IDcount, IDs, KEYID, and encoded data, described after the are flags, IDcount, IDs, KEYID, and encoded data, described after the
grammar. grammar.
1. A TLV will have the word "-TLV" suffix at the end of its name 1. A TLV will have the word "-TLV" suffix at the end of its name
2. An ILV will have the word "-ILV" suffix at the end of its name 2. An ILV will have the word "-ILV" suffix at the end of its name
3. / is used to separate alternatives 3. / is used to separate alternatives
4. parenthesized elements are treated as a single item 4. parenthesized elements are treated as a single item
5. * before an item indicates 0 or more repetitions 5. * before an item indicates 0 or more repetitions
6. 1* before an item indicates 1 or more repetitions 6. 1* before an item indicates 1 or more repetitions
7. [] around an item indicates that it is optional (equal to *1) 7. [] around an item indicates that it is optional (equal to 1*)
The BNF of the PL level PDU is as follows: The BNF of the PL level PDU is as follows:
PL level PDU := MAINHDR [MAIN-TLV] PL level PDU := MAINHDR MAINSELECT
MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] / MAINHDR := The PL PDU header defined in section "Common Header"
[ASResult-TLV] / [ASTreason-TLV] MAINSELECT := ASSOCIATION / ASSOCIATION-RESP / ASSOCIATION-TEAR /
LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV CONFIG / CONFIG-RESP / QUERY / QUERY-RESP /
OPER-TLV := 1*PATH-DATA-TLV EVENT / REDIRECT / HEARTBEAT
ASSOCIATION := LFBselect-TLV
ASSOCIATION-RESP := ASResult-TLV
ASSOCIATION-TEAR := ASTreason-TLV
CONFIG := 1*[LFBselect-TLV]
CONFIG-RESP := 1*[LFBselect-TLV]
QUERY := LFBselect-TLV
QUERY-RESP := LFBselect-TLV
EVENT := LFBselect-TLV
REDIRECT := REDIRECT-TLV
HEARTBEAT := empty message as described in section "Heartbeat Message"
LFBselect-TLV := LFBCLASSID LFBInstance 1*OPERSELECT
LFBCLASSID := the LFB Class ID
LFBInstance := the instance of the LFB class
ASResult-TLV := carries the Association Setup result code
ASTreason-TLV := carries the Association Teardown reason
OPERSELECT := 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
SPARSEDATA-TLV := encoded data that may have optionally
appearing elements
FULLDATA-TLV := encoded data element which may nest FULLDATA-TLV := encoded data element which may nest
further FULLDATA-TLVs further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally
appearing elements
RESULT-TLV := Holds result code and optional FULLDATA-TLV RESULT-TLV := Holds result code and optional FULLDATA-TLV
Figure 13: BNF of PL level PDU Figure 17: BNF of PL level PDU
o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR
also defines the content. As an example the content of a "config" also defines the content. As an example the content of a "config"
message would be different from an "association" message. message would be different from an "association" message. The
table below illustrates the different message types.
o MAIN-TLV is one of several TLVs that could follow the Mainheader. +----------------------------+--------------+---------------+
The appearance of these TLVs is message type specific. | Message Name | Numeric Type | Reference |
+----------------------------+--------------+---------------+
| Association Setup | 0x1 | Section 7.4.1 |
| | | |
| Association Setup Response | 0x11 | Section 7.4.2 |
| | | |
| Association Teardown | 0x02 | Section 7.4.3 |
| | | |
| Config | 0x03 | Section 7.5.1 |
| | | |
| Config Response | 0x13 | Section 7.5.2 |
| | | |
| Query | 0x04 | Section 7.6.1 |
| | | |
| Query Response | 0x14 | Section 7.6.2 |
| | | |
| Event Notification | 0x05 | Section 7.7 |
| | | |
| Packet Redirect | 0x06 | Section 7.8 |
| | | |
| Heartbeat | 0x0F | Section 7.9 |
+----------------------------+--------------+---------------+
o LFBCLASSID is a 32 bit unique identifier per LFB class defined at Table 1
class Definition time.
o LFBInstance is a 32 bit unique instance identifier of an LFB class o MAINSELECT is a place holder to select one of several TLVs that
could follow the common header. The appearance of these TLVs is
message type specific and is demonstrated in the table below.
o OPER-TLV uses the Type field in the TLV to uniquely identify the +----------------+------------+-------------------------------------+
type of operation i.e one of {SET, GET, DEL,etc.} depending on the | Message | MAINSELECT | OPERSELECT |
message type. +----------------+------------+-------------------------------------+
| Association | LFBselect | REPORT |
| Setup | | |
| | | |
| Association | ASRresult | None |
| Setup Response | | |
| | | |
| Association | ASTreason | None |
| Teardown | | |
| | | |
| Config | LFBselect | SET, DEL, COMMIT, SET-PROPERTY |
| | | |
| Config | LFBselect | SET-RESPONSE, DEL-RESPONSE, |
| Response | | SET-PROPERTY-RESPONSE, |
| | | COMMIT-RESPONSE |
| | | |
| Query | LFBselect | GET, GET-PROPERTY |
| | | |
| Query Response | LFBselect | GET-RESPONSE, GET-PROPERTY-RESPONSE |
| | | |
| Event | LFBselect | REPORT |
| Notification | | |
| | | |
| Packet | Redirect | None |
| Redirect | | |
| | | |
| Heartbeat | None | None |
+----------------+------------+-------------------------------------+
Table 2
o When an LFB class is defined, it is assigned a unique value as an
identifier. LFBCLASSID contains such an identifier.
o LFBInstance is the identifier of a particular instance of an LFB
class.
o OPERSELECT is a place holder in the grammar to select the TLV to
uniquely identify the type of operation.
o LFBselect is a TLV that is used by some messages as shown in the
grammar above. Table 2 illustrates what each message type could
have in terms of MAINSELECT and OPERSELECT restrictions.
o PATH-DATA-TLV identifies the exact element targeted and may have o PATH-DATA-TLV identifies the exact element 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 requests and GET response is terminated by encoded data or SET, SET-PROPERTY requests and GET-RESPONSE/GET-PROPERTY-RESPONSE
response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or is terminated by encoded data or response in the form of either
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 bit): count of 32 bit IDs
* IDs: zero or more 32bit IDs (whose count is given by IDcount) * IDs: zero or more 32bit 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
skipping to change at page 36, line 33 skipping to change at page 47, line 42
entry selection. 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 represent the field or fields which 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 1
or more further PATH-DATA selection. FULLDATA and SPARSEDATA are or more further PATH-DATA selection. FULLDATA and SPARSEDATA are
only allowed on SET requests, or on responses which return content only allowed on SET or SET-PROPERTY requests, or on responses
information (GET-RESPONSE for example). PATH-DATA may be included which return content information (GET-RESPONSE for example).
to extend the path on any request. 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 and SPARSEDATA contain "the data" whose path has been * FULLDATA and SPARSEDATA contain "the data" whose path has been
selected by the PATH. Refer to Section 7.1.1.1 for details. selected by the PATH. Refer to Section 7.1.1.1 for details.
o RESULT contains the indication of whether the individual SET * The following table summarizes the applicability and
succeeded. If there is an indication for verbose response, then restrictions of the FULL/SPARSEDATA TLV and the RESULT TLV to
SET-RESPONSE will also contain the FULLDATA TLV showing the data the OPERSELECTs.
that was set. RESULT-TLV is included on the assumption that
individual parts of a SET request can succeed or fail separately. +-----------------------+-------------+----------------+------------+
| OPERSELECT | FULLDATA | SPARSEDATA TLV | RESULT TLV |
| | TLV | | |
+-----------------------+-------------+----------------+------------+
| SET | MAY | MAY | MUST NOT |
| | | | |
| SET-PROPERTY | MAY | MAY | MUST NOT |
| | | | |
| SET-RESPONSE | MAY | MUST NOT | MUST |
| | | | |
| SET-PROPERTY-RESPONSE | MAY | MAY | MUST NOT |
| | | | |
| DEL | MAY | MAY | MUST NOT |
| | | | |
| DEL-RESPONSE | MAY | MUST NOT | MUST |
| | | | |
| GET | MUST NOT | MUST NOT | MUST NOT |
| | | | |
| GET-PROPERTY | MUST NOT | MUST NOT | MUST NOT |
| | | | |
| GET-RESPONSE | MUST | MUST NOT | MAY |
| | | | |
| GET-PROPERTY-RESPONSE | MUST | MUST NOT | MAY |
| | | | |
| REPORT | MAY | MUST NOT | MUST NOT |
| | | | |
| COMMIT | MUST NOT | MUST NOT | MUST NOT |
| | | | |
| COMMIT-RESPONSE | MUST NOT | MUST NOT | MAY |
+-----------------------+-------------+----------------+------------+
Table 3
o RESULT contains the indication of whether the individual SET or
SET-PROPERTY succeeded. If there is a request for verbose
response, then SET-RESPONSE or SET-PROPERTY-RESPONSE will also
contain the FULLDATA TLV showing the data that was set. RESULT-
TLV is included on the assumption that individual parts of a SET
request can succeed or fail separately.
In summary this approach has the following characteristic: In summary this approach has the following characteristic:
o There can be one or more LFB Class + InstanceId combination o There can be one or more LFB class ID and instance ID combination
targeted in a message (batch) targeted in a message (batch)
o There can one or more operations on an addressed LFB classid+
instanceid combination (batch) o There can one or more operations on an addressed LFB class ID/
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 classid+instance targeting. To target multiple instances single LFB class ID and instance ID targeting. To target multiple
within the same class, multiple LFBselect are needed. instances within the same class, multiple LFBselects are needed.
7.1.1.1. Discussion on Grammar
In the case of FULLDATA encoding, data is packed in such a way that a
receiver of such data with knowledge of the path can correlate what
it means by inferring in the LFB definition. This is an optimization
that helps reducing the amount of description for the data in the
protocol.
In other words:
It is assumed that the type of the data can be inferred by the 7.1.1.1. Discussion on encoding
context in which data is used. Hence, data will not include its type
information. The basis for the inference is typically the LFB class
id and the path.
It is expected that a substantial number of operations in ForCES will Section 6.4.3 discusses the two types of DATA encodings (FULLDATA and
need to reference optional data within larger structures. For this SPARSEDATA TLV) and the justifications for their existence. In this
reason, the SPARSEDATA encoding is introduced to make it easier to section we explain how they are encoded.
encapsulate optionally appearing data elements.
7.1.1.1.1. Data Packing Rules 7.1.1.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 doc 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
example of such a setup refer to Appendix D and Appendix C. example of such a setup refer to Appendix C and Appendix 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's "V" will contain that table's row TLV, then the FULLDATA's "V" will contain that table's row
content prefixed by its 32 bit index/subscript. OTOH, when content prefixed by its 32 bit index/subscript. On the other
PATH flags are 00, the PATH may contain an index pointing to a hand, when PATH flags are 00, the PATH may contain an index
row in table; in such a case, the FULLDATA's "V" will only pointing to a row in table; in such a case, the FULLDATA's "V"
contain the content with the index in order to avoid ambiguity. will only contain the content with the index in order to avoid
ambiguity.
7.1.1.1.2. Path Flags 7.1.1.1.2. Path Flags
The following flags are currently defined: The following flags are currently defined:
o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present
following this path information, and should be considered in following this path information, and should be considered in
evaluating the path. evaluating the path.
o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set.
skipping to change at page 38, line 32 skipping to change at page 50, line 25
indicates that although the path identifies an array, the SET indicates that although the path identifies an array, the SET
operation should be applied to the first unused element in the operation should be applied to the first unused element in the
array. The result of the operation will not have this flag set, array. The result of the operation will not have this flag set,
and will have the assigned index in the path. and will have the assigned index in the path.
Example: For a given LFB class, the path 2.5 might select an Example: For a given LFB class, the path 2.5 might select an
array in a structure. If one wanted to set element 6 in this array in a structure. If one wanted to set element 6 in this
array, then the path 2.5.6 would define that element. However array, then the path 2.5.6 would define that element. However
if one wanted to create an element in the first empty spot in if one wanted to create an element in the first empty spot in
the array, the CE would then send the TLV with the FIND-EMPTY the array, the CE would then send the TLV with the FIND-EMPTY
bit set with the path set to 2.5. bit set with the path set to 2.5. Essentially,this is an
optimization so as to not require the CE to fully track all the
tables.
7.1.1.1.3. Relation of operational flags with global message flags 7.1.1.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.1.1.4. Content Path Selection 7.1.1.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.1.1.5. LFB select TLV 7.1.1.1.5. LFBselect-TLV
The LFB select TLV is an instance of TLV defined in Section 6.2. The The LFBselect TLV is an instance of a TLV as defined in Section 6.2.
definition is as below: The definition is as below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | OPERSELECT |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | OPERSELECT |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PL PDU layout Figure 18: 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.
Operation TLV: OPERSELECT:
It describes an operation nested in the LFB select TLV. Note It describes an operation nested in the LFBselect TLV. Note that
that usually there SHOULD be at least one Operation TLV present usually there SHOULD be at least one OPERSELECT present for an
for an LFB select TLV, but for the Association Setup Message LFB select TLV, but for the Association Setup Message defined in
defined in Section 7.4.1. the Operation TLV is optional. In this Section 7.4.1. the OPERSELECT is optional.
case there might not be an Operation TLV followed in the LFB
select TLV.
7.1.1.1.6. Operation TLV 7.1.1.1.6. OPERSELECT
The Operation TLV is an instance of TLV defined in Section 6.2. It The OPERSELECT is a place holder in the grammar for TLVs that define
is assumed that specific operations are identified by the Type code operations. The different types are defined in Table 4, below.
of the TLV. Definitions for individual Types of operation TLVs are
in corresponding message description sections followed.
SET and GET Requests do not have result information (they are +-----------------------+--------+----------------------------------+
requests). SET and GET Responses have result information. SET and | OPERSELECT | TLV | Comments |
GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. | | "Type" | |
+-----------------------+--------+----------------------------------+
| SET | 0x0001 | From CE to FE. Used to create |
| | | or add or update attributes |
| | | |
| SET-PROPERTY | 0x0002 | From CE to FE. Used to create |
| | | or add or update attributes |
| | | |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET |
| | | |
| SET-PROPERTY-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROPERTY |
| | | |
| DEL | 0x0005 | From CE to FE. Used to delete |
| | | or remove an attribute |
| | | |
| DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry |
| | | response of a DEL |
| | | |
| GET | 0x0007 | From CE to FE. Used to retrieve |
| | | an attribute |
| | | |
| GET-PROPERTY | 0x0008 | From CE to FE. Used to retrieve |
| | | an attribute property |
| | | |
| GET-RESPONSE | 0x0009 | From FE to CE. Used to carry |
| | | response of a GET |
| | | |
| GET-PROPERTY-RESPONSE | 0x000A | From FE to CE. Used to carry |
| | | response of a GET-PROPERTY |
| | | |
| REPORT | 0x000B | From FE to CE. Used to carry an |
| | | asynchronous event |
| | | |
| COMMIT | 0x000C | From CE to FE. Used to issue a |
| | | commit in a 2PC transaction |
| | | |
| COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to |
| | | confirm a commit in a 2PC |
| | | transaction |
+-----------------------+--------+----------------------------------+
For a GET response, individual GETs which succeed will have FULLDATA Table 4
Different messages define OPERSELECT are valid and how they are used
(refer to Table 2 and Table 3).
SET, SET-PROPERTY, and GET/GET-PROPERTY requests are issued by the CE
and do not carry RESULT TLVs. On the other hand, SET-RESPONSE, SET-
PROPERTY-RESPONSE and GET-RESPONSE/GET-PROPERTY-RESPONSE carry RESULT
TLVs.
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
elements 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, each FULLDATA or or SPARSEDATA TLV in the For a SET-RESPONSE/SET-PROPERTY-RESPONSE, each FULLDATA or SPARSEDATA
original request will be replaced with a RESULT TLV in the response. TLV in the original request will be replaced with a RESULT TLV in the
If the request was for Ack-fail, then only those items which failed response. If the request set the FailureACK flag, then only those
will appear in the response. If the request was for ack-all, then items which failed will appear in the response. If the request was
all elements of the request will appear in the response with RESULT for AlwaysACK, then all elements of the request will appear in the
TLVs. response with RESULT TLVs.
Note that if a SET request with a structure in a FULLDATA is issued, Note that if a SET/SET-PROPERTY request with a structure in a
and some field in the structure is invalid, the FE will not attempt FULLDATA is issued, and some field in the structure is invalid, the
to indicate which field was invalid, but rather will indicate that FE will not attempt to indicate which field was invalid, but rather
the operation failed. Note further that if there are multiple errors will indicate that the operation failed. Note further that if there
in a single leaf path-data / FULLDATA, the FE can select which error are multiple errors in a single leaf PATH-DATA/FULLDATA, the FE can
it chooses to return. So if a FULLDATA for a SET of a structure select which error it chooses to return. So if a FULLDATA for a SET/
attempts to write one field which is read only, and attempts to set SET-PROPERTY of a structure attempts to write one field which is read
another field to an invalid value, the FE can return whatever error only, and attempts to set another field to an invalid value, the FE
it likes. can return indication of either error.
A SET operation on a variable length element with a length of 0 for A SET/SET-PROPERTY operation on a variable length element with a
the item is not the same as deleting it. If the CE wishes to delete length of 0 for the item is not the same as deleting it. If the CE
then the DEL operation should be used whether the path refers to an wishes to delete then the DEL operation should be used whether the
array element or an optional structure element. path refers to an array element or an optional structure element.
7.1.1.1.7. Result TLV 7.1.1.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 below:
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 | Length | | Type = RESULT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved | | Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Result TLV Figure 19: Result TLV
Defined Result Values
The defined Result Values are
0x00 = Success
0x01 = Unspecified error with header.
0x02 = Header length field does not match actual packet length.
0x03 = Unresolvable mismatch in versions.
0x04 = Destination PID is invalid for the message receiver.
0x05 = LFB Class ID is not known by receiver.
0x06 = LFB Class ID is known by receiver but not currently in use.
0x07 = LFB Class ID is known but the specified instance of that
class does not exist.
0x08 = The specified path is impossible.
0x09 = The specified path is possible but the element does not exist
(e.g., attempt to modify a table row that has not been created).
0x0A = The specified object exists but it cannot exist for the
operation to succeed (e.g., attempt to add an existing LFB
instance or array subscript).
0x0B = The specified object does not exist but it must exist for the
operation to succeed (e.g., attempt to delete an non-existing
LFB instance or array subscript).
0x0C = Attempt to modify a read-only value.
0x0D = Attempt to create an array with an unallowed subscript.
0x0E = Attempt to set a parameter to a value outside of its
allowable range.
0x0D = Attempt to write contents larger than the target object space
(i.e., exceeding a buffer).
0x10 = Any other error with data parameters.
0x11 = Message type is not acceptable.
0x12 = Message flags are not acceptable for the given message type.
0x13 = A TLV is not acceptable for the given message type.
0x14 = Unspecified error while handling an event.
0x15 = Attempt to perform a valid ForCES operation that is
unsupported by the message receiver.
0x16 = A memory error occurred while processing a message (no error
detected in the message itself)
0x17 = An unspecified error occured while processing a message (no
error detected in the message itself).
others = Reserved +-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success |
| | | |
| E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. |
| | | |
| E_LENGTH_MISMATCH | 0x02 | Header length field |
| | | does not match actual |
| | | packet length. |
| | | |
| E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch |
| | | in versions. |
| | | |
| E_INVALID_DESTINATION_PID | 0x04 | Destination PID is |
| | | invalid for the message |
| | | receiver. |
| | | |
| E_LFB_UNKNOWN | 0x05 | LFB Class ID is not |
| | | known by receiver. |
| | | |
| E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known |
| | | by receiver but not |
| | | currently in use. |
| | | |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified |
| | | instance of that class |
| | | does not exist. |
| | | |
| E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. |
| | | |
| E_ELEMENT_DOES_NOT_EXIST | 0x09 | The specified path is |
| | | possible but the |
| | | element does not exist |
| | | (e.g., attempt to |
| | | modify a table row that |
| | | has not been created). |
| | | |
| E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot |
| | | exist for the operation |
| | | to succeed (e.g., |
| | | attempt to add an |
| | | existing LFB instance |
| | | or array subscript). |
| | | |
| E_NOT_FOUND | 0x0B | The specified object |
| | | does not exist but it |
| | | must exist for the |
| | | operation to succeed |
| | | (e.g., attempt to |
| | | delete a non-existing |
| | | LFB instance or array |
| | | subscript). |
| | | |
| E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. |
| | | |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
| | | array with an unallowed |
| | | subscript. |
| | | |
| E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a |
| | | parameter to a value |
| | | outside of its |
| | | allowable range. |
| | | |
| E_CONTENTS_TOO_LONG | 0x0D | Attempt to write |
| | | contents larger than |
| | | the target object space |
| | | (i.e., exceeding a |
| | | buffer). |
| | | |
| E_INVALID_PARAMETERS | 0x10 | Any other error with |
| | | data parameters. |
| | | |
| E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not |
| | | acceptable. |
| | | |
| E_INVALID_FLAGS | 0x12 | Message flags are not |
| | | acceptable for the |
| | | given message type. |
| | | |
| E_INVALID_TLV | 0x13 | A TLV is not acceptable |
| | | for the given message |
| | | type. |
| E_EVENT_ERROR | 0x14 | Unspecified error while |
| | | handling an event. |
| | | |
| E_NOT_SUPPORTED | 0x15 | Attempt to perform a |
| | | valid ForCES operation |
| | | that is unsupported by |
| | | the message receiver. |
| | | |
| E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a |
| | | message (no error |
| | | detected in the message |
| | | itself) |
| | | |
| E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occured while |
| | | processing a message |
| | | (no error detected in |
| | | the message itself) |
| | | |
| - | 0x18-0xFE | Reserved |
| | | |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE can not |
| | | decide what went wrong) |
+-----------------------------+-----------+-------------------------+
0xFF = unspecified error (for when the FE can not decide what went Table 5
wrong)
7.1.1.1.8. DATA TLV 7.1.1.1.8. DATA TLV
A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the
data value/contents. Likewise, a SPARSEDATA TLV has "T" = data value/contents. Likewise, a SPARSEDATA TLV has "T" =
SPARSEDATA, a 16bit Length followed by the data value/contents. In SPARSEDATA, a 16-bit Length, followed by the data value/contents. In
the case of the SPARSEDATA each element in the Value part of the TLV the case of the SPARSEDATA, each element in the Value part of the TLV
will be further encapsulated in an ILV. Rules: will be further encapsulated in an ILV.
1. Both ILVs and TLVs MUST 32 bit aligned. Any padding bits used Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs.
Appendix C is very useful in illustrating these rules:
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 TLV may be used at a particular path only if every 2. FULLDATA TLVs may be used at a particular path only if every
element at that path level is present. This requirement holds element at that path level is present. In example 1(c) of
whether the fields are fixed or variable length, mandatory or Appendix C this concept is illustrated by the presence of all
optional. elements of the structure S in the FULLDATA TLV encoding. This
requirement holds regardless of whether the fields are fixed or
variable length, mandatory or optional.
* If a FULLDATA TLV is used, the encoder MUST layout data for * If a FULLDATA TLV is used, the encoder MUST layout data for
each element in the same order in which the data was defined each element in the same order in which the data was defined
in the LFB specification. This ensures the decoder is in the LFB specification. This ensures the decoder is able to
guaranteed to retrieve the data. retrieve the data. To use the example 1 again in Appendix C,
this implies the encoder/decoder is assumed to have knowledge
of how structure S is laid out in the definition.
* In the case of a SPARSEDATA, it does not need to be ordered * In the case of a SPARSEDATA, it does not need to be ordered
since the "I" in the ILV uniquely identifies the element. since the "I" in the ILV uniquely identifies the element.
Examples 1(a) and 1(b) illustrate the power of SPARSEDATA
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 or ILV encapsulation.
* The values for atomic, variable-length fields are given inside * The values for atomic, variable-length fields are given inside
FULLDATA TLVs. FULLDATA TLVs.
4. Inside a SPARSE TLV 4. Inside a SPARSEDATA TLV
* the values for atomic fields may be given with ILVs (32-bit * The values for atomic fields may 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. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot
contain a FULLDATA. This is because it is hard to disambiguate contain a FULLDATA. This is because it is hard to disambiguate
ILV since an I is 32 bit and a T is 16 bit. ILV since an I is 32 bits and a T is 16 bits.
6. A FULLDATA can also contain a FULLDATA for variable sized 6. A FULLDATA can also contain a FULLDATA for variable sized
elements. The decoding disambiguation is assumed from rule #3 elements. The decoding disambiguation is assumed from rule #3
above. above.
7.1.1.1.9. SET and GET Relationship 7.1.1.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 being a GET-RESPONSE will contain
FULLDATA TLVs. FULLDATA TLVs.
o it should be possible to take the same GET-RESPONSE and convert it o It should be possible to take the same GET-RESPONSE and convert it
to a SET-REPLACE successfully by merely changing the T in the to a SET successfully by merely changing the T in the operational
operational TLV. 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 the that selector is not returned in the GET-RESPONSE; instead the
cooked result is returned. Refer to the examples using KEYS cooked result is returned. Refer to the examples using KEYS
to see this. 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.1.2. Protocol Visualization 7.1.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 operation.
main hdr (Config in this case) main hdr (Config in this case)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID | +-- LFBCLASSID
| | | |
| | | |
| +-- LFBInstance | +-- LFBInstance
| | | |
| +-- T = SET-CREATE | +-- T = SET
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // with their data here to be added | | // with their data here to be added
| | | |
| +-- T = DEL | +-- T = DEL
| . | | . |
| . +-- // one or more path targets to be deleted | . +-- // one or more path targets to be deleted
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID | +-- LFBCLASSID
| | | |
| | | |
| +-- LFBInstance | +-- LFBInstance
| | | |
| + -- T= SET-REPLACE | + -- T= SET
| | | | .
| | | | .
| + -- T= DEL | + -- T= DEL
| | .
| | .
| | | |
| + -- T= SET-REPLACE | + -- T= SET
| | .
| | .
| |
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID +-- LFBCLASSID
| |
+-- LFBInstance +-- LFBInstance
. .
. .
. .
Figure 16: PL PDU logical layout Figure 20: PL PDU logical layout
The figure below shows an example general layout 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 target path.
T = SET-CREATE The figure below shows a more detailed example of the general layout
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
target path.
T = SET
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
skipping to change at page 45, line 35 skipping to change at page 60, line 39
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| + -- T = KEYINFO | + -- T = KEYINFO
| | + -- KEY_ID | | + -- KEY_ID
| | + -- KEY_DATA | | + -- KEY_DATA
| | | |
| + -- T = FULLDATA | + -- T = FULLDATA
| + -- data | + -- data
| |
| |
T = SET-REPLACE T = SET
| | | |
| +- T = Path-data | +- T = Path-data
| | | | | |
| | + -- flags | | + -- flags
| | + -- IDCount | | + -- IDCount
| | + -- IDs | | + -- IDs
| | | | | |
| | + -- T = FULLDATA | | + -- T = FULLDATA
| | + -- data | | + -- data
| +- T = Path-data | +- T = Path-data
skipping to change at page 46, line 35 skipping to change at page 61, line 38
+ -- IDs + -- IDs
+ -- T = KEYINFO + -- T = KEYINFO
| + -- KEY_ID | + -- KEY_ID
| + -- KEY_DATA | + -- KEY_DATA
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
Figure 17: Sample operation layout Figure 21: Sample operation layout
Appendix D shows a more concise set of use-cases on how the data
encoding is done.
7.2. Core ForCES LFBs 7.2. 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 attributes 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.2.1. FE Protocol LFB 7.2.1. FE Protocol LFB
skipping to change at page 47, line 22 skipping to change at page 62, line 29
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 0x1. The FE Protocol LFB Instance ID is assigned assigned the value 0x1. 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 attributes 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 LFB can be found in The formal definition of the FE Protocol Object LFB can be found in
Appendix B. Appendix B.
The FE Protocol LFB consists of the following elements: 7.2.1.1. FE Protocol capabilities
o FE Protocol capabilities (read-only): FE Protocol capabilities are read-only.
* Supported ForCES protocol version(s) by the FE 7.2.1.1.1. SupportableVersions
* Any TML capability description(s) ForCES protocol version(s) supported by the FE
o FE Protocol attributes (can be read and set): 7.2.1.1.2. FE Protocol Attributes
* Current version of the ForCES protocol FE Protocol attributes (can be read and set).
* FE unicast ID 7.2.1.1.2.1. CurrentRunningVersion
* FE multicast ID(s) list - this is a list of multicast IDs that Current running version of the ForCES protocol
the FE belongs to. These IDs are configured by the CE.
* CE heartbeat policy - This policy, along with the parameter 'CE 7.2.1.1.2.2. FEID
Heartbeat Dead Interval (CE HDI)' as described below defines
the operating parameters for the FE to check the CE liveness.
The policy values with meanings are listed as below:
0 (default) - This policy specifies that the CE will send a FE unicast ID
Heartbeat Message to the FE(s) whenever the CE reaches a
time interval within which no other PL messages were sent
from the CE to the FE(s); refer to Section 4.3.3 for
details. The CE HDI attribute as described below is tied to
this policy. If the FE has not received any PL messages
within a CE HDI period it declares the connectivity lost.
The CE independently chooses the time interval for sending
the Heartbeat messages to FE(s) - care must be exercised to
ensure the CE->FE HB interval is smaller than the assigned
CE HDI.
CE HDI SHOULD be at least 3 times as long as the HB 7.2.1.1.2.3. MulticastFEIDs
interval. Shorter rates MAY be appropriate in
implementations working across a reliable internal
interface.
1 - The CE will not generate any HB messages. This actually FE multicast ID(s) list - this is a list of multicast IDs that the FE
means CE does not want the FE to check the CE liveness. belongs to. These IDs are configured by the CE.
Others - reserved. 7.2.1.1.2.4. CEHBPolicy
* CE Heartbeat Dead Interval (CE HDI) - The time interval the FE CE heartbeat policy - This policy, along with the parameter 'CE
uses to check the CE liveness. If FE has not received any Heartbeat Dead Interval (CE HDI)' as described below defines the
messages from CE within this time interval, FE deduces lost operating parameters for the FE to check the CE liveness. The policy
connectivity which implies that the CE is dead or the values with meanings are listed as below:
association to the CE is lost. Default value 30 s.
* FE heartbeat policy - This policy, along with the parameter 'FE o 0 (default) - This policy specifies that the CE will send a
Heartbeat Interval (FE HI)', defines the operating parameters Heartbeat Message to the FE(s) whenever the CE reaches a time
for how the FE should behave so that the CE can deduce its interval within which no other PL messages were sent from the CE
liveness. The policy values and the meanings are: to the FE(s); refer to Section 4.3.3 and Section 7.9 for details.
The CE HDI attribute as described below is tied to this policy.
0(default) - The FE should not generate any Heartbeat o 1 - The CE will not generate any HB messages. This actually means
messages. In this scenario, the CE is responsible for CE does not want the FE to check the CE liveness.
checking FE liveness by setting the PL header ACK flag of
the message it sends to AlwaysACK. The FE responds to CE
whenever CE sends such Heartbeat Request Message. Refer to
Section 7.9 and Section 4.3.3 for details.
1 - This policy specifies that FE must actively send a o Others - reserved.
Heartbeat Message if it reaches the time interval assigned
by the FE HI as long as no other messages were sent from FE
to CE during that interval as described in Section 4.3.3.
Others - Reserved. 7.2.1.1.2.5. CEHDI
* FE Heartbeat Interval (FE HI) - The time interval the FE should CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses
use to send HB as long as no other messages were sent from FE to check the CE liveness. If FE has not received any messages from
to CE during that interval as described in Section 4.3.3. The CE within this time interval, FE deduces lost connectivity which
default value for an FE HI is 500ms. implies that the CE is dead or the association to the CE is lost.
Default value 30 s.
* Primary CEID - The CEID that the FE is associated with. 7.2.1.1.2.6. FEHBPolicy
* Backup CEs - The list of backup CEs an FE is associated with. FE heartbeat policy - This policy, along with the parameter 'FE
Refer to Section 9 for details. Heartbeat Interval (FE HI)', defines the operating parameters for how
the FE should behave so that the CE can deduce its liveness. The
policy values and the meanings are:
* FE restart policy - This specifies the behavior of the FE o 0 (default) - The FE should not generate any Heartbeat messages.
during an FE restart. The restart may be from an FE failure or In this scenario, the CE is responsible for checking FE liveness
other reasons that have made FE down and then need to restart. by setting the PL header ACK flag of the message it sends to
The values are defined as below: AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat
Request Message. Refer to Section 7.9 and Section 4.3.3 for
details.
0(default)- just restart the FE from scratch. In this case, o 1 - This policy specifies that FE must actively send a Heartbeat
the FE should start from the pre-association phase. Message if it reaches the time interval assigned by the FE HI as
long as no other messages were sent from FE to CE during that
interval as described in Section 4.3.3.
1 - restart the FE from an intermediate state. In this o Others - Reserved.
case, the FE decides from which state it restarts. For
example, if the FE is able to retain enough information of
pre-association phase after some failure, it then has the
ability to start from the post-association phase in this
case.
Others - Reserved 7.2.1.1.2.7. FEHI
* CE failover policy - This specifies the behavior of the FE FE Heartbeat Interval (FE HI) - The time interval the FE should use
during a CE failure and restart time interval, or when the FE to send HB as long as no other messages were sent from FE to CE
loses the CE association. It should be noted that this policy during that interval as described in Section 4.3.3. The default
in the case of HA only takes effect after total failure to value for an FE HI is 500ms.
connect to a new CE. A timeout parameter, the CE Timeout
Interval (CE TI) is associated with this attribute. Values of
this policy are defined as below:
0(default) - The FE should continue running and do what it 7.2.1.1.2.8. CEID
can even without an associated CE. This basically requires
that the FE support CE Graceful restart. Note that if the
CE still has not been restarted or hasn't been associated
back to the FE, after the CE TI has expired, the FE will go
operationally down.
1 - FE should go down to stop functioning immediately. Primary CEID - The CEID that the FE is associated with.
2 - FE should go inactive to temporarily stop functioning. 7.2.1.1.2.9. LastCEID
If the CE still has not been restarted after a time interval
of specified by the CE TI, the FE will go down completely.
Others - Reserved Last Primary CEID - The CEID of the last CE that that the FE
associated with. This CE ID is reported to the new Primary CEID.
* CE Timeout Interval (CE TI) - The time interval associated with 7.2.1.1.2.10. BackupCEs
the CE failover policy case '0' and '2'. The default value is
set to 300 seconds. Note that it is advisable to set the CE TI The list of backup CEs an FE can use as backups. Refer to Section 8
value much higher than the CE Heartbeat Dead Interval (CE HDI) for details.
since the effect of expiring this parameter is devastating to
the operation of the FE. 7.2.1.1.2.11. CEFailoverPolicy
CE failover policy - This specifies the behavior of the FE when the
association with the CE is lost. There is a very tight relation
between CE failover policy and Section 7.2.1.1.2.8,
Section 7.2.1.1.2.10, Section 7.2.1.1.2.12, and Section 8. When an
association is lost, depending on configuration, one of the policies
listed below is activated.
o 0 (default) - FE should stop functioning immediately and
transition to FE DOWN.
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
Graceful restart (and defines such support in its capabilities).
If the CEFTI expires before the FE re-associates with either the
primary (Section 7.2.1.1.2.8) or one of possibly several backup
CEs (Section 7.2.1.1.2.10), the FE will go operationally down.
o Others - Reserved
7.2.1.1.2.12. CEFTI
CE Failover Timeout Interval (CEFTI) - The time interval associated
with the CE failover policy case '0' and '2'. The default value is
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
effect of expiring this parameter is devastating to the operation of
the FE.
7.2.1.1.2.13. FERestartPolicy
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
that have made FE down and then need to restart. The values are
defined as below:
o 0(default)- Restart the FE from scratch. In this case, the FE
should start from the pre-association phase.
o others - Reserved for future use.
7.2.2. FE Object LFB 7.2.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 attributes 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 [FE- The formal definition of the FE Object LFB can be found in
MODEL]. The model captures the high level properties of the FE that [FE-MODEL]. The model captures the high level properties of the FE
the CE needs to know to begin working with the FE. The class ID for that the CE needs to know to begin working with the FE. The class ID
this LFB Class is also assigned in [FE-MODEL]. The singular instance for this LFB Class is also assigned in [FE-MODEL]. The singular
of this class will always exist, and will always have instance ID 1 instance of this class will always exist, and will always have
within its class. It is common, although not mandatory, for a CE to instance ID 0x1 within its class. It is common, although not
fetch much of the attribute and capability information from this LFB mandatory, for a CE to fetch much of the attribute and capability
instance when the CE begins controlling the operation of the FE. information from this LFB instance when the CE begins controlling the
operation of the FE.
7.3. Semantics of message Direction 7.3. Semantics of Message Direction
Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. Recall: The PL provides a master(CE)-Slave(FE) relationship. The
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 which resides in the FE.
When messages go from the FE->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 which resides in the FE.
7.4. Association Messages 7.4. Association Messages
The ForCES Association messages are used to establish and teardown The ForCES Association messages are used to establish and teardown
associations between FEs and CEs. associations between FEs and CEs.
7.4.1. Association Setup Message 7.4.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 setup 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 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 the setup is successful or
not. The Correlator field in the header is set, so that FE can not. The correlator field in the header is set, so that FE can
correlate the response coming back from CE correctly. The Src ID correlate the response coming back from the CE correctly. The FE
(FE ID) may be set to O in the header which means that the FE may set the source ID to 0 in the header to request that the CE
would like the CE to assign an FE ID for the FE in the setup should assign an FE ID for the FE in the setup response message.
response message.
Message body: Message body:
The association setup message body optionally consists of one or The association setup message body optionally consists of zero,
more LFB select TLV as described in Section 7.1.1.1.5. The one or two LFBselect TLVs, as described in Section 7.1.1.1.5. The
association setup message only operates toward the FE Object and Association Setup message only operates on the FE Object and FE
FE Protocol LFBs, therefore, the LFB class ID in the LFB select Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV
TLV only points to these two kinds of LFBs. only points to these two kinds of LFBs.
The Operation TLV in the LFB select TLV is defined as a 'REPORT' The OPERSELECT in the LFBselect TLV is defined as a 'REPORT'
operation. More than one attribute may be announced in this operation. More than one attribute may be announced in this
message using REPORT operation to let the FE declare its message using 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 attributes like the Heart Beat Interval parameter, etc. contain attributes suggesting values such as the FE HB Interval,
The Operation TLV for event notification is is defined below. or the FEID. The OPERSELECT used is defined below.
Operation TLV for Association Setup: OPERSELECT for Association Setup:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: OPERSELECT
Figure 18: Operation 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 FE to
report something to CE. report something to 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 "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF
definition. The PATH-DATA-TLV for REPORT operation MAY contain definition. The PATH-DATA-TLV for REPORT operation MAY contain
FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data
format. The RESULT-TLV is defined in Section 7.1.1.1.7 and the format. The RESULT-TLV is defined in Section 7.1.1.1.7 and the
FULLDATA-TLV is defined in Section 7.1.1.1.8. FULLDATA-TLV is defined in Section 7.1.1.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 (eg 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 +-- LFBInstance = 0x1
| |
+---OPERSELECT = REPORT
|
+-- Path-data to one or more attributes +-- Path-data to one or more attributes
including suggested HB parameters
Figure 19: PDU Format Figure 23: PDU Format For Association Setup
7.4.2. Association Setup Response Message 7.4.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 the setup is successful or
not, i.e. whether an association is established. not, i.e., whether an association is established.
Message transfer direction: Message transfer direction:
CE to FE CE to FE
Message Header: Message Header:
The Message Type in the header is set MessageType= The Message Type in the header is set MessageType=
'AssociationSetupResponse'. The ACK flag in the header MUST be 'AssociationSetupResponse'. The ACK flag in the header MUST be
ignored, and the setup response message never expects to get any ignored, and the setup response message never expects to get any
more responses from the message receiver (FE). The Correlator more responses from the message receiver (FE). The destination
field in the header MUST be the same as that of the corresponding ID in the header will be set to the source ID in the
association setup message, so that the association setup message corresponding association setup message, unless that source ID
sender can correlate the response correctly. The Dst ID in the was 0. If the corresponding source ID was 0, then the CE will
header will be set to some FE ID value assigned by the CE if the assign an FE ID value and use that value for the destination ID.
FE had requested that in the setup message (by SrcID = 0).
Message body: Message body:
The association setup response message body only consists of one The Association Setup Response message body only consists of one
TLV, the Association Result TLV, the format of which is as TLV, the Association Result TLV, the format of which is as
follows: follows:
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 20: Message Body Figure 24: ASResult OPERSELECT
Type (16 bits): Type (16 bits):
The type of the TLV is "ASRresult". 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. Length of the TLV including the T and L fields, in octets.
Association Setup Result (32 bits): Association Setup Result (32 bits):
This indicates whether the setup msg was successful or whether This indicates whether the setup msg was successful or whether
the FE request was rejected by the CE. the defined values are: the FE request was rejected by the CE. the defined values are:
0 = success 0 = success
1 = FE ID invalid 1 = FE ID invalid
2 = too many associations 2 = permission denied
3 = permission denied
7.4.3. Association Teardown Message 7.4.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= The Message Type in the header is set MessageType=
"AssociationTeardown". The ACK flag MUST be ignored The "AssociationTeardown". The ACK flag MUST be ignored. The
correlator field in the header MUST be set to zero and MUST be correlator field in the header MUST be set to zero and MUST be
ignored by the receiver. ignored by the receiver.
Message Body: Message Body:
The association teardown message body only consists of one TLV, The association teardown message body only consists of one TLV,
the Association Teardown Reason TLV, the format of which is as the Association Teardown Reason TLV, the format of which is as
follows: follows:
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 21: ASTreason TLV Figure 25: 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. Length of the TLV including the T and L fields, in octets.
Teardown Reason (32 bits): Teardown Reason (32 bits):
This indicates the reason why the association is being This indicates the reason why the association is being
terminated. Several reason codes are defined as follows. terminated. Several reason codes are defined as follows.
skipping to change at page 55, line 12 skipping to change at page 70, line 36
a message body that consists of one or more TLV data format. a message body that consists of one or more TLV data format.
Detailed description of the message is as below. Detailed description of the message is as below.
Message transfer direction: Message transfer direction:
CE to FE CE to FE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Config'. The The Message Type in the header is set MessageType= 'Config'. The
ACK flag in the header can be set to any value defined in ACK flag in the header can be set to any value defined in
Section 6.1, to indicate whether or not a response from FE is Section 6.1, to indicate whether or not a response from FE is
expected by the message ( the flag is set to 'NoACK' or expected by the message.
'AlwaysACK'), or to indicate under which conditions a response is
generated (the flag is set to 'SuccessACK' or 'FailureACK'). The
default behavior for the ACK flag is set to always expect a full
response from FE. This happens when the ACK flag is not set to
any defined value. The correlator field in the message header
MUST be set if a response is expected, so that CE can correlate
the response correctly. The correlator field can be ignored if
no response is expected.
Message body: Message body:
The config message body MUST consist of at least one LFB select The config message body MUST consist of at least one LFB select
TLV as described in Section 7.1.1.1.5. The Operation TLV in the TLV as described in Section 7.1.1.1.5. The OPERSELECT in the
LFB select TLV is defined below. LFB select TLV is defined below.
Operation TLV for Config: OPERSELECT for Config:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: OPERSELECT for Config
Figure 22: Operation TLV for Config
Type: Type:
The operation type for config message. two types of operations The operation type for config message. two types of operations
for the config message are defined: for the config message are defined:
Type = "SET" --- this operation is to set LFB attributes Type = "SET" - this operation is to set LFB attributes
Type = "DEL" --- this operation to delete some LFB Type = "SET-PROPERTY" - this operation is to set LFB
attribute properties
Type = "DEL" - this operation to delete some LFB
attributes attributes
Type = "COMMIT" - this operation is sent to the FE to
commit in a 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).
PATH-DATA-TLV: PATH-DATA-TLV:
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 "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF
definition. The restriction on the use of PATH-DATA-TLV for SET definition. The restriction on the use of PATH-DATA-TLV for SET/
operation is, it MUST contain either a FULLDATA or SPARSEDATA SET-PROPERTY operation is that it MUST contain either a FULLDATA
TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on or SPARSEDATA TLV(s), but MUST NOT contain any RESULT-TLV. The
the use of PATH-DATA-TLV for DEL operation is it MAY contain restriction on the use of PATH-DATA-TLV for DEL operation is it
FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT- MAY contain FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain
TLV. The RESULT-TLV is defined in Section 7.1.1.1.7 and FULLDATA any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.1.1.7
and SPARSEDATA TLVs is defined in Section 7.1.1.1.8. and FULLDATA and SPARSEDATA TLVs is defined in Section 7.1.1.1.8.
*Note: For Event subscription, the events will be defined by the *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 (eg type = config) main hdr (type = Config)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET }
| | | |
| +-- LFBCLASSID = target LFB class | +-- // one or more path targets
| | | // associated with FULL or SPARSEDATA TLV(s)
| | |
| +-- LFBInstance = target LFB instance +-- T = operation { DEL }
| |
| |
| +-- T = operation { SET }
| | |
| | +-- // one or more path targets
| | // associated with FULL or SPARSEDATA TLV(s)
| | | |
| +-- T = operation { DEL } | +-- // one or more path targets
| | |
| | +-- // one or more path targets
Figure 23: PDU Format Figure 27: PDU Format for Config
7.5.2. Config Response Message 7.5.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 the Config was successful or not 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 attribute. result of each attribute.
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= 'Config The Message Type in the header is set MessageType= 'Config
Response'. The ACK flag in the header is always ignored, and the Response'. The ACK flag in the header is always ignored, and the
config response message never expects to get any further response Config Response message never expects to get any further response
from the message receiver (CE). The Correlator field in the from the message receiver (CE).
header MUST keep the same as that of the config message to be
responded, so that the config message sender can correlate the
response with the original message correctly.
Message body: Message body:
The config message body MUST consist of at least one LFB select The Config message body MUST consist of at least one LFBselect
TLV as described in Section 7.1.1.1.5. The Operation TLV in the TLV as described in Section 7.1.1.1.5. The OPERSELECT in the
LFB select TLV is defined below. LFB select TLV is defined below.
Operation TLV for Config Response: OPERSELECT for Config Response:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Operation TLV for Config Response Figure 28: OPERSELECT 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 Type = "SET-RESPONSE" - this operation is for the response
response of SET operation of LFB attributes of SET operation of LFB attributes
Type = "DEL-RESPONSE" --- this operation is for the Type = "SET-PROPERTY-RESPONSE" - this operation is for the
response of the DELETE operation of LFB attributes response of SET-PROPERTY operation of LFB attribute
properties
Type = "DEL-RESPONSE" - this operation is for the response
of the DELETE operation of LFB attributes
Type = "COMMIT-RESPONSE" - this operation is sent to the
CE to confirm a commit success in a 2pc transaction. A
COMMIT-RESPONSE 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).
PATH-DATA-TLV: PATH-DATA-TLV:
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 "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF
definition. The restriction on the use of PATH-DATA-TLV for SET- definition. The restriction on the use of PATH-DATA-TLV for SET-
RESPONSE operation is it MUST contain RESULT-TLV(s). The RESPONSE operation is that it MUST contain RESULT-TLV(s). The
restriction on the use of PATH-DATA-TLV for DEL-RESPONSE restriction on the use of PATH-DATA-TLV for DEL-RESPONSE
operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV
is defined in Section 7.1.1.1.7. is defined in Section 7.1.1.1.7.
7.6. Query Messages 7.6. 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 informations like LFB attributes, capabilities, statistics, etc. for informations like LFB attributes, 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.6.1. Query Message 7.6.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 format. Detailed description
of the message is as below. of the message is as below.
Message transfer direction: Message transfer direction:
from CE to FE. from CE to FE
Message Header: Message Header:
The Message Type in the header is set to MessageType= 'Query'. The Message Type in the header is set to MessageType= 'Query'.
The ACK flag in the header is always ignored, and a full response The ACK flag in the header is always ignored, and a full response
for a query message is always expected. The Correlator field in for a query message is always expected. The Correlator field in
the header is set, so that CE can locate the response back from the header is set, so that the CE can locate the response back
FE correctly. from FE correctly.
Message body: Message body:
The query message body MUST consist of at least one LFB select The query message body MUST consist of at least one LFBselect TLV
TLV as described in Section 7.1.1.1.5. The Operation TLV in the as described in Section 7.1.1.1.5. The OPERSELECT in the
LFB select TLV is defined below. LFB select TLV is defined below.
Operation TLV for Query: OPERSELECT for Query:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET | Length | | Type = GET/GET-PROPERTY | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET | | PATH-DATA-TLV for GET/GET-PROPERTY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: TLV for Query Figure 29: TLV for Query
Type: Type:
The operation type for query. One operation type is defined: The operation type for query. Two operation types are defined:
Type = "GET" --- this operation is to request to get LFB Type = "GET" - this operation is to request to get LFB
attributes. attributes.
PATH-DATA-TLV for GET: Type = "GET-PROPERTY" - this operation is to request to
get LFB attributes.
PATH-DATA-TLV for GET/GET-PROPERTY:
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 "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF
definition. The restriction on the use of PATH-DATA-TLV for GET definition. The restriction on the use of PATH-DATA-TLV for GET/
operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV GET-PROPERTY operation is it MUST NOT contain any SPARSEDATA or
and RESULT-TLV in the data format. 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
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET }
| | | |
| +-- LFBCLASSID = target LFB class | +-- // one or more path targets
| | |
| | +-- T = operation { GET }
| +-- LFBInstance = target LFB instance . |
| | . +-- // one or more path targets
| | .
| +-- T = operation { GET }
| | |
| | +-- // one or more path targets
| |
| +-- T = operation { GET }
| | |
| | +-- // one or more path targets
| |
Figure 26: PDU Format Figure 30: PDU Format
7.6.2. Query Response Message 7.6.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 consists 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 below.
Message transfer direction: Message transfer direction:
from FE to CE. from FE to CE
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set to MessageType=
'QueryResponse'. The ACK flag in the header is ignored. As a 'QueryResponse'. The ACK flag in the header is ignored. As a
response itself, the message does not expect a further response response itself, the message does not expect a further response.
anymore. The Correlator field in the header MUST be the same as
that of the associated query, so that the query message sender
can keep track of the response.
Message body: Message body:
The query response message body MUST consist of at least one LFB The Query Response message body MUST consist of at least one
select TLV as described in Section 7.1.1.1.5. The Operation TLV LFBselect TLV as described in Section 7.1.1.1.5. The OPERSELECT
in the LFB select TLV is defined below. in the LFB select TLV is defined below.
Operation TLV for Query Response: OPERSELECT for Query Response:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET-RESPONSE | Length | |Type = GET-RESPONSE/GET-PROPERTY-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE | | PATH-DATA-TLV for GET-RESPONSE/GET-PROPERTY-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: TLV for Query Response Figure 31: TLV for Query Response
Type: Type:
The operation type for query response. One operation type is The operation type for query response. One operation type is
defined: defined:
Type = "GET-RESPONSE" --- this operation is to response to Type = "GET-RESPONSE" - this operation is to response to
get operation of LFB attributes. get operation of LFB attributes.
PATH-DATA-TLV for GET-RESPONSE: Type = "GET-PROPERTY-RESPONSE" - this operation is to
response to GET-PROPERTY operation of LFB attributes.
PATH-DATA-TLV for GET-RESPONSE/GET-PROPERTY-RESPONSE:
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 "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF
definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY
contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the
data encoding. The RESULT-TLV is defined in Section 7.1.1.1.7 data encoding. The RESULT-TLV is defined in Section 7.1.1.1.7
and the SPARSEDATA and FULLDATA TLVs are defined in and the SPARSEDATA and FULLDATA TLVs are defined in
Section 7.1.1.1.8. Section 7.1.1.1.8.
7.7. Event Notification Message 7.7. Event Notification Message
Event Notification Message is used by FE to asynchronously notify CE Event Notification Message is used by FE to asynchronously notify CE
of events that happen in the FE. of events that happen in the FE.
All events that can be generated in an FE are subscribable by CE. A All events that can be generated in an FE are subscribable by the CE.
config message is used by CE to subscribe/unsubscribe for an event in The CE can subscribe to an event via a Config message with SET-
FE. To subscribe to an event is usually by specifying to the path of PROPERTY operation, where the included path specifies the event, as
such an event as described by FE-Model and defined by LFB library. 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. format. Detailed description of the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE FE to CE
Message Header: Message Header:
The Message Type in the message header is set to The Message Type in the message header is set to
MessageType = 'EventNotification'. The ACK flag in the header MessageType = 'EventNotification'. The ACK flag in the header
MUST be ignored by the CE, and the event notification message does MUST be ignored by the CE, and the event notification message does
not expect any response from the receiver. The Correlator field not expect any response from the receiver.
in the header is also ignored because the response is not
expected.
Message Body: Message Body:
The event notification message body MUST consist of at least one The event notification message body MUST consist of at least one
LFB select TLV as described in Section 7.1.1.1.5. The Operation LFBselect TLV as described in Section 7.1.1.1.5. The OPERSELECT
TLV in the LFB select TLV is defined below. in the LFBselect TLV is defined below.
Operation TLV for Event Notification: OPERSELECT for Event Notification:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: TLV for Event Notification Figure 32: TLV for Event Notification
Type: Type:
Only one operation type is defined for the event notification Only one operation type is defined for the event notification
message: message:
Type = "REPORT" --- this type of operation is for FE to Type = "REPORT" - this type of operation is for FE to
report something to CE. report something to 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 "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF in "Protocol Grammar" section(Section 7.1) in the PATH-DATA BNF
definition. The PATH-DATA-TLV for REPORT operation MAY contain definition. The PATH-DATA-TLV for REPORT operation MAY contain
FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV
in the data format. 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
|
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { REPORT }
| | | |
| +-- LFBCLASSID = target LFB class | +-- // one or more path targets
| | | // associated with FULL/SPARSE DATA TLV(s)
| | +-- T = operation { REPORT }
| +-- LFBInstance = target LFB instance . |
| | . +-- // one or more path targets
| | . // associated with FULL/SPARSE DATA TLV(s)
| +-- T = operation { REPORT }
| | |
| | +-- // one or more path targets
| | // associated with FULL/SPARSE DATA TLV(s)
| +-- T = operation { REPORT }
| | |
| | +-- // one or more path targets
| | // associated with FULL/SPARSE DATA TLV(s)
Figure 29: PDU Format Figure 33: PDU Format
7.8. Packet Redirect Message 7.8. Packet Redirect Message
Packet redirect message is used to transfer data packets between CE A packet Redirect message is used to transfer data packets between CE
and FE. Usually these data packets are IP packets, though they may and FE. Usually these data packets are control packets but they may
sometimes be associated with some metadata generated by other LFBs in be just data-path packets which need further (exception or high-
the model. They may also occasionally be other protocol packets, touch) processing. It is also feasible that this message carries no
which usually happens when CE and FE are jointly implementing some data packets and rather just metadata.
high-touch operations. Packets redirected from FE to CE are the data
packets that come from forwarding plane, and usually are the data
packets that need high-touch operations in CE,or packets for which
the IP destination address is the NE. Packets redirected from CE to
FE are the data packets that come from the CE and that the CE decides
to put into forwarding plane, i.e. an FE.
Supplying such a redirect path between CE and FE actually leads to a
possibility of this path being DoS attacked. Attackers may
maliciously try to send huge spurious packets that will be redirected
by FE to CE, resulting in the redirect path becoming congested.
ForCES protocol and the TML layer will jointly supply approaches to
prevent such DoS attack. To define a specific 'Packet Redirect
Message' makes TML and CE able to distinguish the redirect messages
from other ForCES protocol messages.
By properly configuring related LFBs in FE, a packet can also be
mirrored to CE instead of purely redirected to CE, i.e., the packet
is duplicated and one is redirected to CE and the other continues its
way in the LFB topology.
The Packet Redirect Message data format is formated as follows: The Packet Redirect message data format is formated as follows:
Message Direction: Message Direction:
CE to FE or FE to CE CE to FE or FE to CE
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set to MessageType=
'PacketRedirect'. The ACK flags in the header MUST be ignored, 'PacketRedirect'.
and no response is expected by this message. The correlator field
is also ignored because no response is expected.
Message Body: Message Body:
Consists of (at least) one or more than one TLV that describes This consists of one or more TLVs that contain or describe the
packet redirection. The TLV is specifically a Redirect TLV (with packet being redirected. The TLV is specifically a Redirect TLV
the TLV Type="Redirect"). Detailed data format of a Redirect TLV (with the TLV Type="Redirect"). Detailed data format of a
for packet redirect message is as below: Redirect TLV for packet redirect message is as below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV | | Meta Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV | | Redirect Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Redirect_Data TLV Figure 34: Redirect_Data TLV
LFB class ID:
There are only two possible LFB classes here, the 'RedirectSink'
LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from
FE to CE, the LFB class should be 'RedirectSink'. If the message
is from CE to FE, the LFB class should be 'RedirectSource'.
Instance ID:
Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB.
Meta Data TLV: Meta Data TLV:
This is a TLV that specifies meta-data associated with followed This is a TLV that specifies meta-data associated with followed
redirected data. The TLV is as follows: redirected data. The TLV is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = META-DATA | Length | | Type = METADATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Redirected_Data TLV Figure 35: METADARA TLV
Meta Data ILV: Meta Data ILV:
This is an Identifier-Length-Value format that is used to describe This is an Identifier-Length-Value format that is used to describe
one meta data. The ILV has the format as: one meta data. The ILV has the format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID | | Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value | | Meta Data Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Meta Data ILV Figure 36: 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. This actually implies statically assigned by the LFB definition.
a Meta Data ID transcoding mechanism may be necessary if a
metadata traverses several LFBs while these LFBs define the
metadata with different Meta Data IDs.
Usually there are two meta data that are necessary for CE-FE
redirect operation. One is the redirected data type (e.g., IP
packet, TCP packet, or UDP Packet). For an FE->CE redirect
operation, redirected packet type meta data is usually a meta data
specified by a Classifier LFB that filter out redirected packets
from packet stream and sends the packets to Redirect Sink LFB.
For an CE->FE redirect operation, the redirected packet type meta
data is usually directly generated by CE.
Another meta data that should be associated with redirected data
is the port number in a redirect LFB. For a RedirectSink LFB, the
port number meta data tells CE from which port in the lFB the
redirected data come. For a RedirectSource LFB, via the meta
data, CE tells FE which port in the LFB the redirected data should
go out.
Redirect Data TLV Redirect Data TLV
This is a TLV describing one packet of data to be directed via the This is a TLV describing one packet of data to be directed via the
redirect operation. The TLV format is as follows: redirect operation. The TLV format is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REDIRECTDATA | Length | | Type = REDIRECTDATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data | | Redirected Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Redirect Data TLV Figure 37: Redirect Data TLV
Redirected Data: Redirected Data:
This field presents the whole packet that is to be redirected. This field contains the packet that is to be redirected in network
The packet should be 32bits aligned. byte order. The packet should be 32-bits aligned as is the dat
for all TLVs. The metadata infers what kind of packet is carried
in value field and therefore allows for easy decoding of data
encapsulated
7.9. Heartbeat Message 7.9. 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. same ForCES NE on its liveness. Section 4.3.3 describes the traffic-
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 is
managed as attributes of the FE protocol LFB, and can be set by CE managed as attributes of the FE Protocol Object LFB, and can be set
via a config message. The Heartbeat message is a little different by CE via a Config message. The Heartbeat message is a little
from other protocol messages in that it is only composed of a common different from other protocol messages in that it is only composed of
header, with the message body left empty. Detailed description of a common header, with the message body left empty. A detailed
the message is as below. description of the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE, or CE to FE FE to CE or CE to FE
Message Header: Message Header:
The Message Type in the message header is set to MessageType = The Message Type in the message header is set to MessageType =
'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used.
The ACK flag in the header MUST be set to either 'NoACK' or The ACK flag in the header MUST be set to either 'NoACK' or
'AlwaysACK' when the HB is sent. '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 the HB
policies defined in Section 7.2.1, only the CE can send such policies defined in Section 7.2.1, only the CE can send such
a 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 a 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 a 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 a HB message back immediately. The HB message sent by the FE
in response to the 'AlwasyACK' MUST modify the source and in response to the 'AlwasyACK' 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 CEID of the sender is the destination ID, and MUST change the CE ID of the sender is the destination ID, and MUST
the ACK information to 'NoACK'. A CE MUST NOT respond to an change the ACK information to 'NoACK'. A CE MUST NOT respond
HB message with 'AlwasyACK' set. to an HB message with 'AlwasyACK' set.
* When set to anything else other than 'NoACK' or 'AlwaysACK',
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.
7.10. Operation Summary 8. High Availability Support
The following table summarizes the TLVs that compose messages, and
the applicabiity of operation TLVs to the messages.
+---------------------------+-----------+---------------------------+
| Messages | TLVs | Operations |
+---------------------------+-----------+---------------------------+
| Association Setup | LFBselect | REPORT |
| | | |
| Association Setup | ASRresult | None |
| Response | | |
| | | |
| Association Teardown | ASTreason | None |
| | | |
| Config | LFBselect | SET, DEL |
| | | |
| Config Response | LFBselect | SET-RESPONSE, |
| | | DEL-RESPONSE |
| | | |
| Query | LFBselect | GET |
| | | |
| Query Response | LFBselect | GET-RESPONSE |
| | | |
| Event Notification | LFBselect | REPORT |
| | | |
| Packet Redirect | Redirect | None |
| | | |
| Heartbeat | None | None |
+---------------------------+-----------+---------------------------+
The following table summarises the applicability of the FULL/SPARSE
DATA TLV and the RESULT TLV to the Operation TLVs.
+--------------+--------------+----------------+------------+
| Operations | FULLDATA TLV | SPARSEDATA TLV | RESULT TLV |
+--------------+--------------+----------------+------------+
| SET | MAY | MAY | MUST NOT |
| | | | |
| SET-RESPONSE | MAY | MUST NOT | MUST |
| | | | |
| DEL | MAY | MAY | MUST NOT |
| | | | |
| DEL-RESPONSE | MAY | MUST NOT | MUST |
| | | | |
| GET | MUST NOT | MUST NOT | MUST NOT |
| | | | |
| GET-RESPONSE | MUST | MUST NOT | MAY |
| | | | |
| REPORT | MAY | MUST NOT | MUST NOT |
+--------------+--------------+----------------+------------+
8. Protocol Scenarios
8.1. Association Setup state
The associations among CEs and FEs are initiated via Association
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
FEs are operating in an insecure environment then the security
associations have to be established between them before any
association messages can be exchanged. The TML will take care of
establishing any security associations.
This is typically followed by capability query, topology query, etc.
When the FE is ready to start forwarding data traffic, it sends an FE
UP Event message to the CE. When the CE is ready, it repsonds by
enabling the FE by setting the FEStatus to Adminup [Refer to [FE-
MODEL] for details]. This indicates to the FE to start forwarding
data traffic. At this point the association establishment is
complete. These sequences of messages are illustrated in the Figure
below.
FE PL CE PL
| |
| Asso Setup Req |
|---------------------->|
| |
| Asso Setup Resp |
|<----------------------|
| |
| LFBx Query capability |
|<----------------------|
| |
| LFBx Query Resp |
|---------------------->|
| |
| FEO Query (Topology) |
|<----------------------|
| |
| FEO Query Resp |
|---------------------->|
| |
| Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->|
| |
| FEO UP Event |
|---------------------->|
| |
Figure 34: Message exchange between CE and FE to establish an NE
association
On successful completion of this state, the FE joins the NE.
8.2. Association Established state or Steady State
In this state the FE is continously updated or queried. The FE may
also send asynchronous event notifications to the CE or synchronous
heartbeat messages. This continues until a termination (or
deactivation) is initiated by either the CE or FE. The figure below
helps illustrate this state.
FE PL CE PL
| |
| Heart Beat |
|<---------------------------->|
| |
| Heart Beat |
|----------------------------->|
| |
| Config-set LFBy (Event sub.) |
|<-----------------------------|
| |
| Config Resp LFBy |
|----------------------------->|
| |
| Config-set LFBx Attr |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
|Config-Query LFBz (Stats) |
|<--------------------------- -|
| |
| Query Resp LFBz |
|----------------------------->|
| |
| FE Event Report |
|----------------------------->|
| |
| Config-Del LFBx Attr |
|<-----------------------------|
| |
| Config Resp LFBx |
|----------------------------->|
| |
| Packet Redirect LFBx |
|----------------------------->|
| |
| Heart Beat |
|<-----------------------------|
. .
. .
| |
Figure 35: Message exchange between CE and FE during steady-state
communication
Note that the sequence of messages shown in the figure serve only as
examples and the messages exchange sequences could be different from
what is shown in the figure. Also, note that the protocol scenarios
described in this section do not include all the different message
exchanges which would take place during failover. That is described
in the HA section 8.
9. 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 draft. There can be multiple redundant CEs and FEs of scope of this document. There can be multiple redundant CEs and
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.
Two HA modes are defined in the ForCES protocol, Report Primary Mode 8.1. Relation with the FE Protocol
and Report All Mode. The Report Primary Mode is the default mode of
the protocol, in which the FEs only associate with one CE (primary)
at a time. The Report All mode is for future study and not part of
the current protocol version. In this mode, the FE would establish
association with multiple CEs (primary and secondary) and report
events, packets, Heart Beats to all the CEs. However, only the
primary CE would configure/control the FE in this mode as well. This
would help with keeping state between CEs synchronized, although it
would not guarantee synchronization.
The HA Modes are configured during Association setup phase, though High Availability parameterization in an FE is driven by configuring
currently only Report Primary Mode can be configured. A CE-to-CE the FE Protocol Object LFB (refer to Appendix B and Section 7.2.1).
synchronization protocol would be needed to support fast failover as The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
well as address some of the corner cases, however this will not be Heartbeat policy help in detecting connectivity problems between an
defined by the ForCES protocol as it is out of scope for this FE and CE. The CE Failover policy defines the reaction on a detected
specification. failure.
Figure 38 extends the state machine illustrated in Figure 4 to allow
for new states that facilitate connection recovery.
+-----------------+
Lost association && | Pre-Association |
CE failover policy = 0 | (Association |
+------------>-->--| in +<----+
| | progress) | |
| +--------+--------+ |
| | |
| Y |
| | |
| Associated ^
| | |
| Y |
| | |
| +-------+-------+ |
| CE issues | DOWN FE | |
| FEO Admin | (ForCES | ^
| UP | Active) | |
| +-------- | | |
| | | | |
| | +---------------+ ^
| Y ^ |
| | | |CEFTI expired
| Y |CE issues Admin | &&
| | | DOWN |!connected
| | | ^
| Y | |
+-+-----------+ | +------+------+
| UP |------------+ |Disconnected |
|(associated) | | |
| |Lost association | |
| | && | |
| |--------->------>----->|(Continue |
| |CE failover policy |Forwarding) |
| | = 1 | |
+-------------+ +-------------+
^ |
| Resynchronize !CEFTI expired |
| complete && |
| reconnected |
| +---------------+ |
| | Resynch state | |
| | (via | |
+-----------| graceful |<--------+
| restart) |
+---------------+
Figure 38: FE State Machine considering HA
Section 4.2 describes transitions between the UP, DOWN and Pre-
association states. In this section we deal with disconnected
states.
During a communication failure between the FE and CE (which is caused During a communication failure between the FE and CE (which is caused
due to CE or link reasons, i.e. not FE related), either the TML on due to CE or link reasons, i.e. not FE related), either the TML on
the FE will trigger the FE PL regarding this failure or it will be 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. In the Report Primary mode, as there should be no other existing FE.
CE-FE associations, the FE PL MUST at this point establish
association with the secondary CE. Once the process has started, if
the original primary CE comes alive and starts sending commands
message to the FE, the FE MUST ignore those messages. If the
original CE begins a new association phase with the FE then the FE
MUST send an Association Setup Response message with Result = 2
indicating that there are too many associations. It will be up to
CE-CE communications, out of scope for this specification, to
determine what what, if any changes should be made to FE
configuration following the recovery process.
An explicit message (Config message setting Primary CE attribute in If the FE's FEPO CE Failover Policy is configured to mode 0 (the
ForCES Protocol object) from the primary CE, can also be used to default), it will immediately transition to the pre-association
change the Primary CE for an FE during normal protocol operation. phase. This means that if it ever reconnects again, it will re-
establish state from scratch.
Also note that the FEs in a ForCES NE could also use a multicast If the FE's FEPO CE Failover Policy is configured to mode 1, it
CEID, i.e. they are associated with a group of CEs (this assumes the implies that the FE is capable of HA as well as graceful restart
use of a CE-CE synchronization protocol, which is out of scope for recovery. In such a case, the FE transitions to the disconnected
this specification). In this case the loss of association would mean state and the CEFTI timer is started. The FE continues to forward
that communication with the entire multicast group of CEs has been packets during this state. It also recycles through its configured
lost. The mechanisms described above will apply for this case as secondary CEs in a round-robin fashion. It first adds its primary CE
well during the loss of association. If, however, the secondary CE to the tail of backup CEs and sets its primary CE to be the first
was also using the multicast CEID that was lost, then the FE will secondary. It then attempts to connect to associate with the new
need to form a new association using a different CEID. If the primary CE. If it fails to re-associate with any CE and the CEFTI
capability exists, the FE MAY first attempt to form a new association expires, the FE transitions to the Pre-association state.
with original primary CE using a different non multicast CEID.
These two scenarios, Report Primary (default), Report Primary If the FE, while in the Disconnected state, manages to reconnect to a
(currently unsupported), are illustrated in the Figure 36 and new primary CE before CEFTI expires it transitions to the Resynch
Figure 37 below. state. In the Resynch state, the FE tries to recover any state that
may have been lost during the Disonnected state. Graceful restart is
one such mechanism. How the FE achieves these goals is out of scope
for this document.
Figure 39 below illustrates the Forces message sequences that the FE
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 74, line 46 skipping to change at page 85, line 25
| | | |
| 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 36: CE Failover for Report Primary Mode Figure 39: CE Failover for Report Primary Mode
FE CE Primary CE Secondary
| | |
| Asso Estb,Caps exchg | |
1 |<--------------------->| |
| | |
| Asso Estb,Caps|exchange |
2 |<----------------------|------------------->|
| | |
| All msgs | |
3 |<--------------------->| |
| | |
| packet redirection,|events, HBs |
4 |-----------------------|------------------->|
| | |
| FAILURE |
| |
| Event Report (pri CE down) |
5 |------------------------------------------->|
| |
| All Msgs |
6 |<------------------------------------------>|
Figure 37: CE Failover for Report All mode 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
will not be defined by the ForCES protocol as it is out of scope for
this specification.
9.1. Responsibilities for HA An explicit message (a Config message setting Primary CE attribute in
ForCES Protocol object) from the primary CE, can also be used to
change the Primary CE for an FE during normal protocol operation.
TML level - Transport level: 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
the use of a CE-CE synchronization protocol, which is out of scope
for this specification). In this case, the loss of association would
mean that communication with the entire multicast group of CEs has
been lost. The mechanisms described above will apply for this case
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
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
with original primary CE using a different non multicast CE ID.
8.2. Responsibilities for HA
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 links
going down are the role of the TML. going down are the role of the TML.
PL Level: PL Level:
For all other functionality including configuring the HA behavior All other functionality, including configuring the HA behavior during
during setup, the CEIDs are used to identify primary, 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 messages used to detect association failure, messages to change the
primary CE (config - move), 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 will take the appropriate actions described before. informed and it would take the appropriate actions described before.
10. Security Considerations 9. Security Considerations
ForCES architecture identifies several levels of security in ForCES architecture identifies several levels of security in
[RFC3746]. ForCES PL uses security services provided by the ForCES [RFC3746]. ForCES PL uses security services provided by the ForCES
TML layer. TML layer provides security services such as endpoint TML. The TML provides security services such as endpoint
authentication service, message authentication service and authentication service, message authentication service and
confidentiality service. Endpoint authentication service is invoked confidentiality service. Endpoint authentication service is invoked
at the time of pre-association connection establishment phase and at the time of the pre-association connection establishment phase and
message authentication is performed whenever FE or CE receives a message authentication is performed whenever the FE or CE receives a
packet from its peer. packet from its peer.
The following are the general security mechanisms that needs to be in The following are the general security mechanisms that need to be in
place for ForCES PL layer. 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 only, Confidentiality), it will be in Security, Authentication, Confidentiality), it will be in effect
effect for the entire duration of the session. for the entire duration of the session.
o Operator should configure the same security policies for both o An operator should configure the same security policies for both
primary and backup FE's and CE's (if available). This will ensure primary and backup FEs and CEs (if available). This will ensure
uniform operations, and to avoid unnecessary complexity in policy uniform operations and avoid unnecessary complexity in policy
configuration. configuration.
o ForCES PL endpoints SHOULD pre-established connections with both 9.1. No Security
primary and backup CE's. This will reduce the security messages
and enable rapid switchover operations for HA.
10.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 layer. Both these mechanism are weak and be performed by ForCES PL. Both these mechanism are weak and do not
does not involve cryptographic operation. 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. 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. The operations that are being performed for "No security" level.
level is required even if lower TML security services are being used.
10.1.1. Endpoint Authentication 9.1.1. Endpoint Authentication
Each CE and FE PL layer maintains set of associations list as part of Each CE and FE PL maintains a list of associations as part its of
configuration. This is done via CEM and FEM interfaces. FE MUST configuration. This is done via the CEM and FEM interfaces. An FE
connect to only those CE's that are configured via FEM similarly, a MUST connect to only those CEs that are configured via the FEM;
CE should accept the connection and establish associations for the similarly, a CE should accept the connection and establish
FE's which are configured via CEM. CE should validate the FE associations for the FEs which are configured via the CEM. The CE
identifier before accepting the connection during the pre-association should validate the FE identifier before accepting the connections
phase. during the pre-association phase.
10.1.2. Message authentication 9.1.2. Message authentication
When CE or FE generates initiates a message, the receiving endpoint When a CE or FE initiates a message, the receiving endpoint MUST
MUST validate the initiator of the message by checking the common validate the initiator of the message by checking the common header
header CE or FE identifiers. This will ensure proper protocol CE or FE identifiers. This will ensure proper protocol functioning.
functioning. This extra processing step is recommend even if the This extra processing step is recommend even when underlying provides
underlying TLM layer security services. TLM layer security services exist.
10.2. ForCES PL and TML security service 9.2. ForCES PL and TML security service
This section is applicable if operator wishes to use the TML security This section is applicable if an operator wishes to use the TML
services. ForCES TML layer MUST support one or more security service security services. A ForCES TML MUST support one or more security
such as endpoint authentication service, message authentication services such as endpoint authentication service, message
service, confidentiality service as part of TML security layer authentication service, and confidentiality service, as part of TML
functions. It is the responsibility of the operator to select security layer functions. It is the responsibility of the operator
appropriate security service and configure security policies to select an appropriate security service and configure security
accordingly. The details of such configuration is outside the scope policies accordingly. The details of such configuration are outside
of ForCES PL and is depending upon the type of transport protocol, the scope of the ForCES PL and are dependent on the type of transport
nature of 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 TML layer, When certificates-based authentication is being used at the TML, the
the certificate can use ForCES specific naming structure as certificate can use a ForCES-specific naming structure as certificate
certificate names and accordingly the security policies can be names and, accordingly, the security policies can be configured at
configured at CE and FE. the CE and FE.
10.2.1. Endpoint authentication service 9.2.1. Endpoint authentication service
When TML security services are enabled. ForCES TML layer 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 layer. CE and FE and is transparent to the ForCES PL.
It is recommended that an FE, after establishing the connection with
the primary CE, should establish the security association with the
backup CE (if available). During the switchover operation CE's
security state associated with each SA's are not transferred. SA
between primary CE and FE and backup CE and FE are treated as two
separate SA's.
10.2.2. Message authentication service
This is TML specific operation and is transparent to ForCES PL layer. 9.2.2. Message authentication service
For details refer to Section 5. This is a TML specific operation and is transparent to the ForCES PL.
For details, refer to Section 5.
10.2.3. Confidentiality service 9.2.3. Confidentiality service
This is TML specific operation and is transparent to ForCES PL layer. 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.
11. Acknowledgments 10. Acknowledgments
The authors of this draft would like to acknowledge and thank the The authors of this draft 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, Joel M.
Halpern (who should probably be listed among the authors), 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 Droz for their comments and suggestions on the protocol and Patrick Droz for their comments and suggestions on the protocol and
for their infinite patience. for their infinite patience. We would also like to thank Sue Hares
and Alia Atlas for extensive reviews of the document.
Alia Atlas has done a wonderful job of shaping the draft to make it
more readable by providing the IESG feedback.
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. tools. The editor is also grateful to Elwyn Davies for his help in
correcting the XML source of this document.
12. References 11. References
12.1. Normative References 11.1. Normative References
[FE-MODEL] [FE-MODEL]
Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,
and S. Blake, "ForCES Forwarding Element Model", and S. Blake, "ForCES Forwarding Element Model",
Feb. 2005. 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.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[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.
12.2. Informational References 11.2. Informational References
[2PCREF] Gray, J., "Notes on database operating systems. In [2PCREF] Gray, J., "Notes on database operating systems. In
Operating Systems: An Advanced Course. Lecture Notes in Operating Systems: An Advanced Course. Lecture Notes in
Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 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,
skipping to change at page 82, line 27 skipping to change at page 91, line 27
o TLV Type Section 7.1.1 o TLV Type Section 7.1.1
o TLV Result Values Section 7.1.1.1.7 o TLV Result Values Section 7.1.1.1.7
o LFB Class ID Section 7.1.1.1.5 o LFB Class ID Section 7.1.1.1.5
o Result: Association Setup Response Section 7.4.2 o Result: Association Setup Response Section 7.4.2
o Reason: Association Teardown Message Section 7.4.3 o Reason: Association Teardown Message Section 7.4.3
o Configuration Request: Operation Result Section 7.5.1
A.1. Message Type Name Space A.1. Message Type Name Space
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 - 0x0F
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. [RFC2434] consensus action. [RFC2434]
Values assigned by this specification: Values assigned by this specification:
skipping to change at page 83, line 7 skipping to change at page 92, line 7
0x06 PacketRedirect 0x06 PacketRedirect
0x07 - 0x0E Reserved 0x07 - 0x0E Reserved
0x0F Hearbeat 0x0F Hearbeat
0x11 AssociationSetupRepsonse 0x11 AssociationSetupRepsonse
0x12 Reserved 0x12 Reserved
0x13 ConfigRepsonse 0x13 ConfigRepsonse
0x14 QueryResponse 0x14 QueryResponse
Message Types 0x20 - 0x7F Message Types 0x20 - 0x7F
Message Types in this range are Specification Required [RFC2434] Message Types in this range are Specification Required [RFC2434]
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 references. 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 this range of the Message Type Name Space is
unnecessary. unnecessary.
A.2. Operation Type A.2. Operation Selection
The Operation Type name space is 16 bits long. The following is the The Operation Selection (OPERSELECT) name space is 16 bits long. The
guideline for managing the Operation Type Name Space. following is the guideline for managing the OPERSELECT Name Space.
Operation Type 0x0000-0x00FF OPERSELECT Type 0x0000-0x00FF
Operation Types in this range are allocated through an IETF OPERSELECT Types in this range are allocated through an IETF
consensus process. [RFC2434]. consensus process. [RFC2434].
Values assigned by this specification: Values assigned by this specification:
0x0000 Reserved 0x0000 Reserved
0x0001 SET 0x0001 SET
0x0002 SET-RESPONSE 0x0002 SET-PROPERTY
0x0003 DEL 0x0003 SET-RESPONSE
0x0004 DEL-RESPONSE 0x0004 SET-PROPERTY-RESPONSE
0x0005 GET 0x0005 DEL
0x0006 GET-RESPONSE 0x0006 DEL-RESPONSE
0x0007 REPORT 0x0007 GET
0x0008 GET-PROPERTY
0x0009 GET-RESPONSE
0x000A GET-PROPERTY-RESPONSE
0x000B REPORT
0x000C COMMIT
0x000D COMMIT-RESPONSE
Operation Type 0x0100-0x7FFF OPERSELECT Type 0x0100-0x7FFF
Operation Types using this range must be documented in an RFC or OPERSELECT Types using this range must be documented in an RFC or
other permanent and readily available references. [RFC2434]. other permanent and readily available reference. [RFC2434].
Operation Type 0x8000-0xFFFF OPERSELECT Type 0x8000-0xFFFF
Operation Types in this range are reserved for vendor private OPERSELECT 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 Operation Type Name Space is management of this range of the OPERSELECT Type Name Space is
unnecessary. unnecessary.
A.3. Header Flags A.3. Header Flags
The Header flag field is 32 bits long Header flags are part of the The Header flag field is 32 bits long. Header flags are part of
ForCES base protocol. Header flags are allocated through an IETF the ForCES base protocol. Header flags are allocated through an
consensus action [RFC2434]. IETF consensus action [RFC2434].
A.4. TLV Type Name Space A.4. TLV Type Name Space
The TLV Type name space is 16 bits long. The following is the The TLV Type name space is 16 bits long. The following is the
guideline for managing the TLV Type Name Space. guideline for managing the TLV Type Name Space.
TLV Type 0x0000-0x00FF TLV Type 0x0000-0x00FF
TLV Types in this range are allocated through an IETF consensus TLV Types in this range are allocated through an IETF consensus
process. [RFC2434]. process. [RFC2434].
Values assigned by this specification: Values assigned by this specification:
0x0000 Reserved 0x0000 Reserved
0x0001 MAIN_TLV 0x0001 REDIRECT-TLV
0x0002 REDIRECT-TLV
0x0010 ASResult-TLV 0x0010 ASResult-TLV
0x0011 ASTreason-TLV 0x0011 ASTreason-TLV
0x1000 LFBselect-TLV 0x1000 LFBselect-TLV
0x0101 OPER-TLV
0x0110 PATH-DATA-TLV 0x0110 PATH-DATA-TLV
0x0111 KEYINFO-TLV 0x0111 KEYINFO-TLV
0x0112 FULLDATA-TLV 0x0112 FULLDATA-TLV
0x0113 SPARSEDATA-TLV 0x0113 SPARSEDATA-TLV
0x0114 RESULT-TLV 0x0114 RESULT-TLV
0x0115 METADATA-TLV
0x0116 REDIRECTDATA-TLV
TLV Type 0x0200-0x7FFF TLV Type 0x0200-0x7FFF
TLV Types using this range must be documented in an RFC or other TLV Types using this range must be documented in an RFC or other
permanent and readily available references. [RFC2434]. permanent and readily available reference [RFC2434].
TLV Type 0x8000-0xFFFF TLV Type 0x8000-0xFFFF
TLV Types in this range are reserved for vendor private extensions TLV Types in this range are reserved for vendor private extensions
and are the responsibility of individual vendors. IANA management and are the responsibility of individual vendors. IANA management
of this range of the TLV Type Name Space is unnecessary. of this range of the TLV Type Name Space is unnecessary.
A.5. Result-TLV Result Values A.5. Result-TLV Result Values
The RESULT-TLV RTesult Value is an 8 bit value. The RESULT-TLV RTesult Value is an 8 bit value.
0x00 SUCCESS 0x00 E_SUCCESS
0x01 INVALID_HEADER 0x01 E_INVALID_HEADER
0x02 LENGTH_MISMATCH 0x02 E_LENGTH_MISMATCH
0x03 VERSION_MISMATCH 0x03 E_VERSION_MISMATCH
0x04 INVALID_DESTINATION_PID 0x04 E_INVALID_DESTINATION_PID
0x05 LFB_UNKNOWN 0x05 E_LFB_UNKNOWN
0x06 LFB_NOT_FOUND 0x06 E_LFB_NOT_FOUND
0x07 LFB_INSTANCE_ID_NOT_FOUND 0x07 E_LFB_INSTANCE_ID_NOT_FOUND
0x08 INVALID_PATH 0x08 E_INVALID_PATH
0x09 ELEMENT_DOES_NOT_EXIST 0x09 E_ELEMENT_DOES_NOT_EXIST
0x0A EXISTS 0x0A E_EXISTS
0x0B NOT_FOUND 0x0B E_NOT_FOUND
0x0C READ_ONLY 0x0C E_READ_ONLY
0x0D INVALID_ARRAY_CREATION 0x0D E_INVALID_ARRAY_CREATION
0x0E VALUE_OUT_OF_RANGE 0x0E E_VALUE_OUT_OF_RANGE
0x0F CONTENTS_TOO_LONG 0x0F E_CONTENTS_TOO_LONG
0x10 INVALID_PARAMETERS 0x10 E_INVALID_PARAMETERS
0x11 INVALID_MESSAGE_TYPE 0x11 E_INVALID_MESSAGE_TYPE
0x12 INVALID_FLAGS 0x12 E_E_INVALID_FLAGS
0x13 INVALID_TLV 0x13 E_INVALID_TLV
0x14 EVENT_ERROR 0x14 E_EVENT_ERROR
0x15 NOT_SUPPORTED 0x15 E_NOT_SUPPORTED
0x16 MEMORY_ERROR 0x16 E_MEMORY_ERROR
0x17 INTERNAL_ERROR 0x17 E_INTERNAL_ERROR
0x18-0xFE Reserved 0x18-0xFE Reserved
0xFF UNSPECIFIED_ERROR 0xFF E_UNSPECIFIED_ERROR
All values not assigned in this specification are designated as All values not assigned in this specification are designated as
Assignment by Expert review. Assignment by Expert review.
A.6. LFB Class Id Name Space A.6. Association Setup Response
The LFB Class ID name space is 32 bits long. The following is the
guideline for managing the LFB Class Id Name Space.
LFB Class ID 0x00000000-0x0000FFFF
LFB Class IDs in this range are allocated through an IETF
consensus process. [RFC2434].
Values assigned by this specification:
0x00000000 Reserved
0x00000001 FE Protocol LFB
0x00000002 FE Object LFB
LFB Class ID 0x00010000-0x7FFFFFFF
LFB Class IDs in this range are Specification Required [RFC2434]
LFB Class ID using this range must be documented in an RFC or
other permanent and readily available references. [RFC2434].
LFB Class Id 0x80000000-0xFFFFFFFFF
LFB Class IDs in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA
management of this range of the LFB Class ID Space is unnecessary.
A.7. Association Setup Response
The Association Setup Response name space is 16 bits long. The The Association Setup Response name space is 32 bits long. The
following is the guideline for managing the Association Setup following is the guideline for managing the Association Setup
Response Name Space. Response Name Space.
Association Setup Response 0x0000-0x00FF Association Setup Response 0x0000-0x00FF
Association Setup Responses in this range are allocated through an Association Setup Responses in this range are allocated through an
IETF consensus process. [RFC2434]. IETF consensus process [RFC2434].
Values assigned by th