draft-ietf-forces-protocol-06.txt   draft-ietf-forces-protocol-07.txt 
Network Working Group A. Doria (Ed.) Network Working Group A. Doria (Ed.)
Internet-Draft ETRI Internet-Draft ETRI
Expires: June 16, 2006 R. Haas (Ed.) Expires: September 6, 2006 R. Haas (Ed.)
IBM 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
December 12, 2005
March 5, 2006
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-06.txt draft-ietf-forces-protocol-07.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 42
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 June 16, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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, co-authors and co- The participants in the ForCES Protocol Team, primary co-authors and
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 (ETRI), Ram
Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M
Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University).
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11
4.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 13 4.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 13
4.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 14 4.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 14
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 17 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18
4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 19 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 19
4.3.1. Transactions, Atomicity, Execution and Responses . . 19 4.3.1. Transactions, Atomicity, Execution and Responses . . 19
4.3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 21 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 23
4.3.3. FE Object and FE protocol LFBs . . . . . . . . . . . 22 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 23
4.3.4. Scalability . . . . . . . . . . . . . . . . . . . . . 22 4.3.4. FE Object and FE protocol LFBs . . . . . . . . . . . 24
5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 24 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 25
5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 25 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 26
6. Message encapsulation . . . . . . . . . . . . . . . . . . . . 26 6. Message encapsulation . . . . . . . . . . . . . . . . . . . . 27
6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 30 6.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 32
6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 31 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 32
6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 31 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 32
6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 33 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 34
7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 33 7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 34
7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 33 7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 34
7.1.2. Protocol Visualization . . . . . . . . . . . . . . . 41 7.1.2. Protocol Visualization . . . . . . . . . . . . . . . 42
7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 44 7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 45
7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 45 7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 46
7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 48 7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 49
7.3. Semantics of message Direction . . . . . . . . . . . . . 48 7.3. Semantics of message Direction . . . . . . . . . . . . . 49
7.4. Association Messages . . . . . . . . . . . . . . . . . . 48 7.4. Association Messages . . . . . . . . . . . . . . . . . . 49
7.4.1. Association Setup Message . . . . . . . . . . . . . . 48 7.4.1. Association Setup Message . . . . . . . . . . . . . . 49
7.4.2. Association Setup Response Message . . . . . . . . . 50 7.4.2. Association Setup Response Message . . . . . . . . . 51
7.4.3. Association Teardown Message . . . . . . . . . . . . 51 7.4.3. Association Teardown Message . . . . . . . . . . . . 52
7.5. Configuration Messages . . . . . . . . . . . . . . . . . 52 7.5. Configuration Messages . . . . . . . . . . . . . . . . . 53
7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 52 7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 53
7.5.2. Config Response Message . . . . . . . . . . . . . . . 54 7.5.2. Config Response Message . . . . . . . . . . . . . . . 55
7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 55 7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 56
7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 55 7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 57
7.6.2. Query Response Message . . . . . . . . . . . . . . . 57 7.6.2. Query Response Message . . . . . . . . . . . . . . . 58
7.7. Event Notification Message . . . . . . . . . . . . . . . 58 7.7. Event Notification Message . . . . . . . . . . . . . . . 59
7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 60 7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 61
7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 63 7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 64
7.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 64 7.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 65
8. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 66 8. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 68
8.1. Association Setup state . . . . . . . . . . . . . . . . . 66 8.1. Association Setup state . . . . . . . . . . . . . . . . . 68
8.2. Association Established state or Steady State . . . . . . 67 8.2. Association Established state or Steady State . . . . . . 69
9. High Availability Support . . . . . . . . . . . . . . . . . . 70 9. High Availability Support . . . . . . . . . . . . . . . . . . 72
9.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 72 9.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 74
10. Security Considerations . . . . . . . . . . . . . . . . . . . 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 76
10.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 73 10.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 76
10.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 73 10.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 76
10.1.2. Message authentication . . . . . . . . . . . . . . . 74 10.1.2. Message authentication . . . . . . . . . . . . . . . 77
10.2. ForCES PL and TML security service . . . . . . . . . . . 74 10.2. ForCES PL and TML security service . . . . . . . . . . . 77
10.2.1. Endpoint authentication service . . . . . . . . . . . 74 10.2.1. Endpoint authentication service . . . . . . . . . . . 77
10.2.2. Message authentication service . . . . . . . . . . . 74 10.2.2. Message authentication service . . . . . . . . . . . 77
10.2.3. Confidentiality service . . . . . . . . . . . . . . . 75 10.2.3. Confidentiality service . . . . . . . . . . . . . . . 78
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
12.1. Normative References . . . . . . . . . . . . . . . . . . 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 80
12.2. Informational References . . . . . . . . . . . . . . . . 77 12.2. Informational References . . . . . . . . . . . . . . . . 80
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 78 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 81
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 78 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 81
A.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 79 A.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 82
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 79 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 82
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 79 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 83
A.5. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 80 A.5. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 83
A.6. Association Setup Response . . . . . . . . . . . . . . . 81 A.6. Association Setup Response . . . . . . . . . . . . . . . 84
A.7. Association Teardown Message . . . . . . . . . . . . . . 81 A.7. Association Teardown Message . . . . . . . . . . . . . . 84
A.8. Configuration Request Result . . . . . . . . . . . . . . 82 A.8. Configuration Request Result . . . . . . . . . . . . . . 85
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 83 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 86
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 88 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 91
B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 88 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 91
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 89 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 92
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 93 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 96
Appendix E. Changes between -05 and -06; Post WGLC . . . . . . . 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 Intellectual Property and Copyright Statements . . . . . . . . . 114
Intellectual Property and Copyright Statements . . . . . . . . . 113
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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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. ForCES FE model [FE-MODEL]
presents the capabilities, state and configuration of FEs within the presents the capabilities, state and configuration of FEs within the
context of the ForCES protocol, so that CEs can accordingly control context of the ForCES protocol, so that CEs can accordingly control
the FEs in a standardizded way and by means of the ForCES protocol. the FEs in a standardizded way and by means of 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. Information exchanged between FEs and CEs makes
extensive use of TLVs. The protocol includes commands for transport extensive use of TLVs. The protocol includes commands for transport
of LFB configuration information as well as for association, status, of LFB configuration information, association setup, status and event
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, but does include a discussion of service primitives that
must be provided by the underlying transport interface. must be provided by the underlying transport interface.
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 discussion
on the protocol framework, descriptions of the Protocol Layer (PL) on the protocol framework, descriptions of the Protocol Layer (PL)
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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 several Protocol Scenarios and includes message
exchange descriptions. exchange descriptions.
Section 9 describes mechanism in the protocol to support high Section 9 describes a mechanism in the protocol to support high
availability mechanisms including redundancy and fail over. availability mechanisms including redundancy and fail over.
Section 10 defines the security mechanisms provided by the PL and Section 10 defines the security mechanisms provided by the PL and
TML. 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].
This document also uses the terminology defined by ForCES the FE The definitions below are repeated below for clarity.
model in [FE-MODEL]. The definitons 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 Forwarding Element (FE) - A logical entity that implements the ForCES
protocol. FEs use the underlying hardware to provide per-packet protocol. FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by a CE via the ForCES processing and handling as directed/controlled by a CE via the ForCES
skipping to change at page 9, line 27 skipping to change at page 9, line 25
firewall, and L7 content recognition. firewall, and L7 content recognition.
Datapath -- A conceptual path taken by packets within the forwarding Datapath -- A conceptual path taken by packets within the forwarding
plane inside an FE. plane inside an FE.
LFB (Logical Function Block) -- The basic building block that is 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 LFB configuration entity that is operated on by the CE. Note that the
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 LFB (Logical Function Block) and LFB Instance -- LFBs are categorized
by LFB Classes(or Types). An LFB Instance represents an LFB Class by LFB Classes(or Types). An LFB Instance represents an LFB Class
(or Type) existence. There may be multiple instances of the same LFB (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 (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. 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 As a result, an LFB Class ID associated with an LFB Instance ID
uniquely specify an LFB existence. uniquely specify an LFB existence.
skipping to change at page 10, line 19 skipping to change at page 10, line 17
FE Topology -- A representation of how the multiple FEs within a FE Topology -- A representation of how the multiple FEs within a
single NE are interconnected. Sometimes this is called inter-FE single NE are interconnected. Sometimes this is called inter-FE
topology, to be distinguished from intra-FE topology (i.e., LFB topology, to be distinguished from intra-FE topology (i.e., LFB
topology). topology).
Inter-FE Topology -- See FE Topology. Inter-FE Topology -- See FE Topology.
Intra-FE Topology -- See LFB Topology. Intra-FE Topology -- See LFB Topology.
The following terms are defined by this document:
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
skipping to change at page 12, line 4 skipping to change at page 12, line 4
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 and Fe, is element configuration (indicated by reference points Fc, Ff, and Fl)
out of scope of the ForCES protocol but is touched on in this is out of scope of the ForCES protocol but is touched on in this
document in discussion of FEM and CEM since it is an integral part of document in discussion of FEM and CEM since it is an integral part of
the protocol pre-association phase. 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 |. . . |
| | | | | | | | | | | | | |
skipping to change at page 14, line 6 skipping to change at page 14, line 6
On transmit, the PL layer delivers its messages to the TML layer. On transmit, the PL layer delivers its messages to the TML layer.
The TML layer delivers the message to the destination TML layer(s). The TML layer delivers the message to the destination TML layer(s).
On receive, the TML delivers the message to its destination PL On receive, the TML delivers the message to its destination PL
layer(s). layer(s).
4.1.1. The PL layer 4.1.1. The PL layer
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 layer is responsible
for associating an FE or CE to an NE. It is also responsible for for associating an FE or CE to an NE. It is also responsible for
tearing down such associations. An FE uses the PL layer to trasmit tearing down such associations. An FE uses the PL layer to transmit
various subscribed-to events to the CE PL layer as well as to respond various subscribed-to events to the CE PL layer as well as to respond
to various status requests issued from the CE PL. The CE configures to various status requests issued from the CE PL. The CE configures
both the FE and associated LFBs' operational parameters using the PL both the FE and associated LFBs' operational parameters using the PL
layer. In addition the CE may send various requests to the FE to layer. In addition the CE may send various requests to the FE to
activate or deactivate it, reconfigure its HA parameterization, activate or deactivate it, reconfigure its HA parameterization,
subscribe to specific events etc. More details can be found in subscribe to specific events etc. More details can be found in
Section 7. Section 7.
4.1.2. The TML layer 4.1.2. The TML layer
The TML layer transports the PL layer messages. The TML is where the The TML layer transports the PL layer messages. The TML is where the
issues of how to achieve transport level reliability, congestion issues of how to achieve transport level reliability, congestion
control, multicast, ordering, etc. are handled. It is expected more control, multicast, ordering, etc. are handled. It is expected more
than one TML will be standardized. The various possible TMLs could than one TML will be standardized. The various possible TMLs could
vary their implementations based on the capabilities of underlying vary their implementations based on the capabilities of underlying
media and transport. However, since each TML is standardized, media 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 should be same TML. All ForCES Protocol Layer implementations MUST be portable
portable across all TMLs, because all TMLs MUST have the top edge across all TMLs, because all TMLs MUST have the top edge semantics
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 layers, are out of scope of the
ForCES protocol. The best way to think of them are as ForCES protocol. The best way to think of them are as
configurations/parameterizations for the PL and TML before they configurations/parameterizations for the PL and TML before they
become active (or even at runtime based on implementation). In the become active (or even at runtime based on implementation). In the
simplest case, the FE or CE read a static configuration file. RFC simplest case, the FE or CE read a static configuration file. RFC
3746 has a more detailed descriptions on how the FEM and CEM could be 3746 has a more detailed descriptions on how the FEM and CEM could be
used. The pre-association phase, where the CEM and FEM can be sued, used. The pre-association phase, where the CEM and FEM can be used,
are described briefly in Section 4.2.1. are described briefly in Section 4.2.1.
An example of typical of things the FEM/CEM could configure would be An example of typical of things the FEM/CEM could configure would be
TML specific parameterizations such as: TML specific parameterizations such as:
a. how the TML connection should happen (example what IP addresses a. how the TML connection should happen (for example what IP
to use, transport modes etc); addresses to use, transport modes etc);
b. Issuing the ID for the FE or CE would also be issued at this b. Issuing the ID for the FE or CE would also be issued during the
point. 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: "send up to 3 association messages each 1 second apart" Vs " Example of this might be:
send up to 4 association messages with increasing exponential
timeout". o simple parameters: send up to 3 association messages every 1
second
o or more complex parameters: send up to 4 association messages with
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.
start FEObject Admin up FE start CE configures
-------+ +--->---->---->---->------->----+ -------+ +--->---->---->---->------->----+
| | Y | | Y
Y | | Y | |
| | Y | | Y
+------+--+ +--------+ +------+--+ +--------+
| | | | | FE | | FE |
| DOWN | | UP | | DOWN | | UP |
| State | | State | | State | | State |
| | | | | | | |
+---------+ +--------+ +---------+ +--------+
^ Y ^ Y
| | | |
+-<---<------<-----<------<----<---+ +-<---<------<-----<------<----<---+
FEObject Admin Down/ CE configures or FE loses association
Association lost
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 The FE can only be in one of two states as indicated above. When the
FE is in the DOWN state, it is not forwarding packets. When the FE FE is in the DOWN state, it is not forwarding packets. When the FE
is in the UP state it may be forwarding packets depending on the is in the UP state it may be forwarding packets depending on the
configuration of its specific LFBs. configuration of its specific LFBs.
On start up the FE is in the DOWN state unless explicitly configured CE configures FE states transitions by means of a so-called FEObject
by the CE to transition to the UP state. This MUST be done before LFB, which is defined in [FE-MODEL] and also explained in Section
configuring any other LFBs that affect packet forwarding. 4.3.3 of this document. In FEObject LFB, FE state is defined as an
attribute of the LFB, and CE configuration of the FE state equals CE
configuration of this attribute. Note that even in the FE DOWN
state, the FEObject LFB itself is active.
The FE transitions from the DOWN to the UP state when explicitly On start up the FE is in the DOWN state unless it is explicitly
configured to do so by the CE or when it loses its association with configured by the CE to transition to the UP state via an FE Object
the CE. For the FE to properly complete the transition to the DOWN admin action. This must be done before configuring any other LFBs
state it MUST stop packet forwarding and that this may affect that affect packet forwarding.
multiple LFBs. How this is achieved is outside the scope of this
specification. The FE transitions from the UP state to the DOWN state when it
receives a FEObject Admin Down action or when it loses its
association with the CE. For the FE to properly complete the
transition to the DOWN state, it MUST stop Packet forwarding and this
may impact 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
skipping to change at page 19, line 8 skipping to change at page 19, line 26
further discussion refer to Section 9 and Appendix B). further discussion refer to Section 9 and Appendix B).
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 windows.
The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP
(Transaction Phase) flag as defined in Common Header Section (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 back 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. requested. These modes relate to the transactional two phase
commitment operations.
4.3.1.1. Execution 4.3.1.1. Execution
There are 3 execution modes that could 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: operations spanning one or more LFB selectors in one protocol
message. The EM flag defined in Common Header Section (Section 6.1)
selects the execution mode for a protocol message, as below:
a. Transactional execute-all-or-none a. execute-all-or-none
b. Loose transactional execute-until-failure b. execute-until-failure
c. Non-transactional continue-execute-on-failure c. continue-execute-on-failure
4.3.1.1.1. 'execute-all-or-none' Atomic transaction 4.3.1.1.1. execute-all-or-none
A transaction may be atomic: When set to this mode, independent operations in a message targeted
at one or more LFB selectors will all be executed if no failure
occurs for any of the operations. If there is any failure for any of
the operations then none of the operations will be executed, i.e
there is roll back for this mode of operation.
a. Within an FE alone 4.3.1.1.2. continue-execute-on-failure
Example: updating multiple tables which are dependent on each
other. If updating one fails, then any others already updated
must be undone.
b. Distributed across the NE If several independent operations are targeted at one or more LFB
Example: updating table(s) that are inter-dependent across selectors, execution continues for all operations at the FE even if
several FEs (such as L3 forwarding related tables). one or more operations fail.
For distributed transactional consistency across FEs, a classical 4.3.1.1.3. execute-until-failure
transactional protocol known as Two Phase Commit (2PC) [2PCREF] is
supported.
4.3.1.1.2. Transaction Definition In this mode all operations are executed on the FE sequentially until
the first failure. The rest of the operations are not executed but
operations already completed are not undone, i.e. there is no roll
back in this mode of operation.
4.3.1.2. Transaction and Atomicity
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:
o *Atomicity*. In a transaction involving two or more discrete Atomicity: In a transaction involving two or more discrete pieces
pieces of information, either all of the pieces are committed or of information, either all of the pieces are committed
none are. or none are.
o *Consistency*. A transaction either creates a new and valid state Consistency: A transaction either creates a new and valid state of
of data, or, if any failure occurs, returns all data to its state data, or, if any failure occurs, returns all data to the
before the transaction was started. state it was in before the transaction was started.
o *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.
o *Durability*. Committed data is saved by the system such that, Committed data is saved by the system such that, even in
even in the event of a failure and 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. For the purpose of to mention that it is not disallowed.
interoperability, a classical transactional protocol known as two
phase commit is defined. This model meets the ACID properties
described in [ACID] to be used for transactions.
4.3.1.1.3. Transaction protocol
A 2PC [2PCREF] configuration message starts with the header flags
containing a Start of Transaction (SOT) and Atomic Transaction (AT)
on its first message configuration message. A transaction may span
multiple messages. It is up to the CE to keep track of the different
outstanding messages making up a transaction. As an example, the
correlator field could be used to mark transactions and a sequence
field to label the different messages within the same atomic
transaction.
Any failure notified by the FE causes the CE to execute an Abort
Transaction (ABT) to all FEs involved in the transaction, rolling
back all previously executed operations in the transaction.
The transaction commitment phase is signaled from the CE to the FE by
an empty End of Transaction (EOT) configuration message.
The FE MUST respond to the CE's EOT message. If no response is As defined above, a transaction is always atomic and MAY be
received from the FE within a specified timeout, the transaction MUST
be aborted by the CE.
4.3.1.1.4. Recovery a. Within an FE alone
Example: updating multiple tables that are dependent on each
other. If updating one fails, then any that were already updated
must be undone.
Any of the participating FEs, or the CE, or the associations between b. Distributed across the NE
them, may fail after the EOT response message has left the FE but Example: updating table(s) that are inter-dependent across
before it has received all the responses, e.g if the EOT response several FEs (such as L3 forwarding related tables).
never reaches the CE.
In this protocol revision, for sake of simplicity as indicated in 4.3.1.2.2. Transaction protocol
Section 4.2.2.3, an FE losing an association would be required to get
new state from the newly associated CE from scratch upon a re-
association. The decision on what an FE should do after a lost
association is dictated by the CE Failover policy (refer to Section 9
and Section 7.2).
4.3.1.1.5. continue-execute-on-failure By use of the execute mode as defined in Section 4.3.1.1, the
protocol has provided a mechanism for transactional operations within
one stand-alone message. The 'execute-all-or-none' mode can meet the
ACID requirements.
If several independent operations are targeted at one or more LFB For transactional operations of multiple messages within one FE or
selectors, execution continues at the FE even if one or more across FEs, a classical transactional protocol known as Two Phase
operations fail. This mode is signaled by AT flag set to zero (0). Commit (2PC) [2PCREF] is supported by the protocol to achieve the
transactional operations.
4.3.1.1.6. execute-until-failure The AT flag and the TP flag in Common Header (Section 6.1) are
provided for 2PC based transactional operations spanning multiple
messages.
In this mode all operations are executed on the FE sequentially until The AT flag, when set, indicates this message belongs to an Atomic
the first failure. The rest of the operations are not executed but Transaction. All messages for a transaction operation must have the
operations already completed are not undone, i.e. there is no roll AT flag set. If not set, it means the message is a stand-alone
back in this mode. message and does not participate in any transaction operation that
spans multiple messages.
4.3.1.1.7. Relation to Multipart messages The TP flag indicates the Transaction Phase this message belongs to.
There are four (4) possible phases for an transactional operation
known as:
Multipart messages, after the first one, are indicated by the Middle SOT (Start of Transaction)
of Transaction flag (MOT). The first message is indicated by SOT and
the last by EOT.
Multi-part messages MUST be consistent in their use of execution MOT (Middle of Transaction)
modes. If the first message starts with one exectution mode (such as
continue-execute-on-failure mode), then all other parts of the same
multi-part messages MUST continue with the same execution mode. Any
inconsistency implies an error and a canceled transaction in which
all messages are dropped and the sender NACKED.
4.3.2. Heartbeat Mechanism EOT (End of Transaction)
Heartbeats (HB) between FEs and CEs are traffic sensitive. A HB is ABT (Abort)
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
HB traffic in the case of busy PL periods.
A HB can be sourced by either the CE or FE. When sourced by the CE, A transaction operation is started with a message the TP flag is set
a response can be requested (similar to the ICMP ping protocol). The to Start of Transaction (SOT). Multi-part messages, after the first
FE can only generate HBs in the case of being configured to do so by one, are indicated by the Middle of Transaction flag (MOT). The last
the CE. Refer to Section 7.2.1 and Section 7.9 for details. message is indicated by by EOT.
4.3.3. FE Object and FE protocol LFBs Any failure notified by the FE causes the CE to execute an Abort
Transaction (ABT) to all FEs involved in the transaction, rolling
back all previously executed operations in the transaction.
All PL messages operate on LFB constructs as this provides more The transaction commitment phase is signaled from the CE to the FE
flexibility for future enhancements. This means that maintenance and by an End of Transaction (EOT) configuration message. The FE MUST
configurability of FEs, NE, as well as the ForCES protocol itself respond to the CE's EOT message. If no response is received from
must be expressed in terms of this LFB architecture. For this reason the FE within a specified timeout, the transaction MUST be aborted
special LFBs are created to accommodate this need. by the CE.
In addition, this shows how the ForCES protocol itself can be Note that a transactional operation is generically atomic, therefore
controlled by the very same type of structures (LFBs) it uses to it requires that the execute modes of all messages in a transaction
control functions such as IP forwarding, filtering, etc. 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
result in a transaction failure.
To achieve this, the following specialized LFBs are introduced: As noted above, a transaction may span multiple messages. It is up
to the CE to keep track of the different outstanding messages making
up a transaction. As an example, the correlator field could be used
to mark transactions and a sequence field to label the different
messages within the same atomic transaction, but this is out of scope
and up to implementations.
o FE Protocol LFB which is used to control the ForCES protocol. 4.3.1.2.3. Recovery
o FE Object LFB which is used to controls attributes relative to the Any of the participating FEs, or the CE, or the associations between
FE itself. Such attributes include FEState (refer to model them, may fail after the EOT response message has been sent by the FE
draft), vendor, etc. but before it has received all the responses, e.g. if the EOT
response never reaches the CE.
These LFBs are detailed in Section 7.2. 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
entirely new state from the newly associated CE upon a re-
association. The decision on what an FE should do after a lost
association is dictated by the CE Failover policy (refer to Section 9
and Section 7.2).
4.3.4. Scalability 4.3.2. Scalability
It is desirable that the PL layer not become the bottleneck when It is desirable that the PL layer not become the bottleneck when
larger bandwidth pipes become available. To pick a hypothetical larger bandwidth pipes become available. To pick a hypothetical
example in today's terms, if a 100Gbps pipe is available and there is example in today's terms, if a 100Gbps pipe is available and there is
sufficient work then the PL layer should be able to take advantage of sufficient work then the PL layer should be able to take advantage of
this and use all of the 100Gbps pipe. Two mechanisms are provided to this and use all of the 100Gbps pipe. Two mechanisms have been
achieve this. The first one is batching and the second one is a provided to achieve this. The first one is batching and the second
command window. one is a command window.
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 part of unrelated transactions that are the same transaction or may be part of unrelated transactions that
independent of each other. are independent of each other.
Command windowing allows for pipelining of independent transactions Command windowing 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.4.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
selector) can be addressed within one PL PDU selector) can be addressed within one PL PDU
o Multiple operations can be addressed to a single LFB class and o Multiple operations can be addressed to a single LFB class and
instance instance
4.3.4.2. Command Pipelining 4.3.2.2. Command Pipelining
The protocol allows any number of messages to be issued by the CE The protocol allows any number of messages to be issued by the CE
before the corresponding acknowledgments (if requested) have been before the corresponding acknowledgments (if requested) have been
returned by the FE. Hence pipelining is inherently supported by the returned by the FE. Hence pipelining is inherently supported by the
protocol. Matching responses with requests messages can be done protocol. Matching responses with requests messages can be done
using the correlator field in the message header. using the correlator field in the message header.
4.3.3. Heartbeat Mechanism
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
configured interval. This has the effect of reducing the amount of
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,
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
the CE. Refer to Section 7.2.1 and Section 7.9 for details.
4.3.4. FE Object and FE protocol LFBs
All PL messages operate on LFB constructs as this provides more
flexibility for future enhancements. This means that maintenance and
configurability of FEs, NE, as well as the ForCES protocol itself
must be expressed in terms of this LFB architecture. For this reason
special LFBs are created to accommodate this need.
In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc.
To achieve this, the following specialized LFBs are introduced:
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
FE itself. Such attributes include FEState [FE-MODEL], vendor,
etc.
These LFBs are detailed in Section 7.2.
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
skipping to change at page 25, line 10 skipping to change at page 26, line 10
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 layer and will provide
preferential treatment. preferential treatment.
TML needs to define how this is achieved. While the TML needs to define how this is achieved, it should be
noted that the requirement for supporting up to 8 priority levels
8. The requirement for supporting up to 8 priority levels does not does not mean that the underlying TML MUST be capable of
mean that the underlying TML MUST be capable of handling up to 8 providing up to 8 actual priority levels. In the event that the
priority levels. In such an event the priority levels should be underlying TML layer does not have support for 8 priority levels,
divided between the available TML priority levels. For example, the supported priority levels should be divided between the
if the TML only supports 2 priority levels, the 0-3 could go in available TML priority levels. For example, if the TML only
one TML priority level, while 4-7 could go in the other. supports 2 priority levels, the 0-3 could go in one TML priority
level, while 4-7 could go in the other.
9. Protection against DoS attacks 8. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6 As described in the Requirements 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
skipping to change at page 26, line 37 skipping to change at page 27, line 37
Figure 7: Common Header Figure 7: 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 SHOULD set it to zero. field. Senders MUST set it to zero and receivers MUST ignore
this field.
Message Type (8 bits): Message Type (8 bits):
Commands are defined in Section 7. Commands are defined in Section 7.
Length (16 bits): Length (16 bits):
length of header + the rest of the message in DWORDS (4 byte length of header + the rest of the message in DWORDS (4 byte
increments). increments).
Source ID (32 bit): Source ID (32 bit):
skipping to change at page 27, line 28 skipping to change at page 28, line 33
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 8: 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:
A. TS Corresponding ID range Assignment TS Corresponding ID range Assignment
-- ---------------------- ----------
B. -- ---------------------- ---------- 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 0b10 0x80000000 to 0xBFFFFFFF reserved
0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16)
D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
0b11 0xFFFFFFFD all CEs broadcast
E. 0b10 0x80000000 to 0xBFFFFFFF reserved 0b11 0xFFFFFFFE all FEs broadcast
0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 -
16)
G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
H. 0b11 0xFFFFFFFD all CEs broadcast
I. 0b11 0xFFFFFFFE all FEs broadcast Figure 9: Type Switch ID Space
J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
* 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.
* 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.
skipping to change at page 28, line 37 skipping to change at page 29, line 32
message sequence identifier. Another example a 64 bit pointer to message sequence identifier. Another example a 64 bit pointer to
a context block. All such implementation specific use of the 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.
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 | EM|TP | Reserved | |ACK| Pri |Rsr |EM |A|TP | Reserved |
| | | | | | | | | vd. | |T| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: 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 config to indicate to the message receiver whether or not a response
response is required by the sender. Note that for all other is required by the sender. Note that for all other messages
messages than Config Message this flag MUST be ignored. than the Config Message or the HB Message this flag MUST be
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.
skipping to change at page 30, line 26 skipping to change at page 31, line 26
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)
This flag indicates if the message is stand-alone message or
one of multiple messages that belongs to 2PC transaction
operations. See Section 4.3.1.2.2 for details.
Stand-alone message ......... (0b0)
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.1.3 for details. Refer to Section 4.3.1.2.2 for details.
`MOT (Middle of transaction)` (0b00) SOT (start of transaction) ..... (0b00)
`SOT (start of transaction)` (0b01) MOT (Middle of transaction) .... (0b01)
`EOT (end of transaction)` (0b10) EOT (end of transaction) ........(0b10)
`ABT (abort)` (11) ABT (abort) .....................(0b11)
6.2. Type Length Value(TLV) Structuring 6.2. Type Length Value(TLV) Structuring
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 | variable TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Data of size TLV length) | | Value (Data of size TLV length) |
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 14 skipping to change at page 32, line 17
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 | variable TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Data of size TLV length) | | Value (Data of size TLV length) |
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TLV Representation Figure 11: 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 indicates the
type of data encapsulated within the TLV. 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 indicates
the length of this TLV including the TLV Type, TLV the length of this TLV including the TLV Type, TLV
Length, and the TLV data in octets. Length, and the TLV data in octets.
skipping to change at page 31, line 41 skipping to change at page 32, line 44
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 an 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 in the PDU hierarchy a Type occurs, it refers to the same wherever TLVs occur in the PDU, a specific Type value refers to the
Type of TLV. This is a design choice to ease debugging of the same Type of TLV. This is a design choice that was made to ease
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 referes 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. The Length part of the ILV is fixed at 32 bits.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ILV Representation Figure 12: 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.
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
skipping to change at page 33, line 35 skipping to change at page 34, line 35
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 *0) 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 [MAIN-TLV]
MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] / MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] /
[ASResult-TLV] / [ASTreason-TLV] [ASResult-TLV] / [ASTreason-TLV]
LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV
OPER-TLV := 1*PATH-DATA-TLV OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA] PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR] PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV 1*PATH-DATA-TLV
KEYINFO-TLV := KEYID FULLDATA-TLV KEYINFO-TLV := KEYID FULLDATA-TLV
SPARSEDATA-TLV := encoded data that may have optionally SPARSEDATA-TLV := encoded data that may have optionally
appearing elements appearing elements
FULLDATA-TLV := encoded data element which may nest FULLDATA-TLV := encoded data element which may nest
further FULLDATA-TLVs further FULLDATA-TLVs
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
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.
o MAIN-TLV is one of several TLVs that could follow the Mainheader. o MAIN-TLV is one of several TLVs that could follow the Mainheader.
The appearance of these TLVs is message type specific. The appearance of these TLVs is message type specific.
o LFBCLASSID is a 32 bit unique identifier per LFB class defined at o LFBCLASSID is a 32 bit unique identifier per LFB class defined at
class Definition time. class Definition time.
skipping to change at page 37, line 27 skipping to change at page 38, line 27
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.
This must only be used on a create operation. If set, this This must only be used on a create operation. If set, this
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
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
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
bit set with the path set to 2.5.
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
Should be noted that other applicable flags such as atomicity Global flags, such as the execution mode and the atomicity indicators
indicators as well as verbosity result formatters are in the main defined in the header, apply to all operations in a message. Global
headers flags area. flags provide semantics that are orthogonal to those provided by the
operational flags, such as the flags defined in Path Data. The scope
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. LFB select TLV
The LFB select TLV is an instance of TLV defined in Section 6.2. The The LFB select TLV is an instance of TLV defined in Section 6.2. The
skipping to change at page 38, line 22 skipping to change at page 39, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: PL PDU layout Figure 14: 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.
skipping to change at page 39, line 7 skipping to change at page 40, line 7
The Operation TLV is an instance of TLV defined in Section 6.2. It The Operation TLV is an instance of TLV defined in Section 6.2. It
is assumed that specific operations are identified by the Type code is assumed that specific operations are identified by the Type code
of the TLV. Definitions for individual Types of operation TLVs are of the TLV. Definitions for individual Types of operation TLVs are
in corresponding message description sections followed. in corresponding message description sections followed.
SET and GET Requests do not have result information (they are SET and GET Requests do not have result information (they are
requests). SET and GET Responses have result information. SET and requests). SET and GET Responses have result information. SET and
GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs.
For a GET response, individual gets which succeed will have FULLDATA For a GET response, individual GETs which succeed 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 elements 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, each FULLDATA or or SPARSEDATA TLV in the
original request will be replaced with a RESULT TLV in the response. original request will be replaced with a RESULT TLV in the response.
If the request was for Ack-fail, then only those items which failed If the request was for Ack-fail, then only those items which failed
will appear in the response. If the request was for ack-all, then will appear in the response. If the request was for ack-all, then
all elements of the request will appear in the response with RESULT all elements of the request will appear in the response with RESULT
TLVs. TLVs.
skipping to change at page 39, line 36 skipping to change at page 40, line 36
another field to an invalid value, the FE can return whatever error another field to an invalid value, the FE can return whatever error
it likes. it likes.
A SET operation on a variable length element with a length of 0 for A SET operation on a variable length element with a length of 0 for
the item is not the same as deleting it. If the CE wishes to delete the item is not the same as deleting it. If the CE wishes to delete
then the DEL operation should be used whether the path refers to an then the DEL operation should be used whether the path refers to an
array element or an optional structure element. array element or an optional structure element.
7.1.1.1.7. Result TLV 7.1.1.1.7. Result TLV
A RESULT TLV contains a 4 octet integer value. The RESULT TLV is an instance of TLV defined in Section 6.2. The
definition is as below:
The defined values are 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Result TLV
The defined Result Values are
0 = success 0 = success
1 = no such object 1 = no such object
2 = permission denied 2 = permission denied (e.g., trying to configure an attribute that
is read- only)
3 = invalid value (the encoded data could not validly be stored in 3 = invalid value (the encoded data could not validly be stored in
the field) the field)
4 = invalid array creation (when the subscript in an array create is 4 = invalid array creation (when the subscript in an array create is
not allowed) not allowed)
255 = unspecified error (for when the FE can not decide what went 255 = unspecified error (for when the FE can not decide what went
wrong) wrong)
others = Reserved
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 16bit 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 16bit 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. Rules:
1. Both ILVs and TLVs MUST 32 bit aligned. If need be they MUST be 1. Both ILVs and TLVs MUST 32 bit aligned. Any padding bits used
padded to achieve the alignment. for the alignment MUST be zero on transmission and MUST be
ignored upon reception.
2. FULLDATA TLV may be used at a particular path only if every 2. FULLDATA TLV 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. This requirement holds
whether the fields are fixed or variable length, mandatory or whether the fields are fixed or variable length, mandatory or
optional. 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
guaranteed to retrieve the data. guaranteed to retrieve the data.
skipping to change at page 42, line 49 skipping to change at page 43, line 49
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID +-- LFBCLASSID
| |
+-- LFBInstance +-- LFBInstance
. .
. .
. .
Figure 14: PL PDU logical layout Figure 16: PL PDU logical layout
The figure below shows an example general layout of the operation The figure below shows an example general layout of the operation
within a targeted LFB selection. The idea is to show the different within a targeted LFB selection. The idea is to show the different
nesting levels a path could take to get to the target path. nesting levels a path could take to get to the target path.
T = SET-CREATE T = SET-CREATE
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
skipping to change at page 44, line 35 skipping to change at page 45, line 35
+ -- 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 15: Sample operation layout Figure 17: Sample operation layout
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
skipping to change at page 45, line 23 skipping to change at page 46, line 23
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 LFB can be found in
Appendix B Appendix B.
The FE Protocol LFB consists of the following elements: The FE Protocol LFB consists of the following elements:
o FE Protocol capabilities (read-only): o FE Protocol capabilities (read-only):
* Supported ForCES protocol version(s) by the FE * Supported ForCES protocol version(s) by the FE
* Any TML capability description(s) * Any TML capability description(s)
o FE Protocol attributes (can be read and set): o FE Protocol attributes (can be read and set):
skipping to change at page 45, line 50 skipping to change at page 46, line 50
the FE belongs to. These IDs are configured by the CE. the FE belongs to. These IDs are configured by the CE.
* CE heartbeat policy - This policy, along with the parameter 'CE * CE heartbeat policy - This policy, along with the parameter 'CE
Heartbeat Dead Interval (CE HDI)' as described below defines Heartbeat Dead Interval (CE HDI)' as described below defines
the operating parameters for the FE to check the CE liveness. the operating parameters for the FE to check the CE liveness.
The policy values with meanings are listed as below: The policy values with meanings are listed as below:
0 (default) - This policy specifies that the CE will send a 0 (default) - This policy specifies that the CE will send a
Heartbeat Message to the FE(s) whenever the CE reaches a Heartbeat Message to the FE(s) whenever the CE reaches a
time interval within which no other PL messages were sent time interval within which no other PL messages were sent
from the CE to the FE(s); refer to Section 4.3.2 for 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 details. The CE HDI attribute as described below is tied to
this policy. If the FE has not received any PL messages this policy. If the FE has not received any PL messages
within a CE HDI period it declares the connectivity lost. within a CE HDI period it declares the connectivity lost.
The CE independently chooses the time interval for sending The CE independently chooses the time interval for sending
the Heartbeat messages to FE(s) - care must be exercised to the Heartbeat messages to FE(s) - care must be exercised to
ensure the CE->FE HB interval is smaller than the assigned ensure the CE->FE HB interval is smaller than the assigned
CE HDI. CE HDI.
CE HDI SHOULD be at least 3 times as long as the HB
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 1 - The CE will not generate any HB messages. This actually
means CE does not want the FE to check the CE liveness. means CE does not want the FE to check the CE liveness.
Others - reserved. Others - reserved.
* CE Heartbeat Dead Interval (CE HDI) - The time interval the FE * CE Heartbeat Dead Interval (CE HDI) - The time interval the FE
uses to check the CE liveness. If FE has not received any uses to check the CE liveness. If FE has not received any
messages from CE within this time interval, FE deduces lost messages from CE within this time interval, FE deduces lost
connectivity which implies that the CE is dead or the connectivity which implies that the CE is dead or the
association to the CE is lost. Default value 30 s. association to the CE is lost. Default value 30 s.
skipping to change at page 46, line 33 skipping to change at page 47, line 38
* FE heartbeat policy - This policy, along with the parameter 'FE * FE heartbeat policy - This policy, along with the parameter 'FE
Heartbeat Interval (FE HI)', defines the operating parameters Heartbeat Interval (FE HI)', defines the operating parameters
for how the FE should behave so that the CE can deduce its for how the FE should behave so that the CE can deduce its
liveness. The policy values and the meanings are: liveness. The policy values and the meanings are:
0(default) - The FE should not generate any Heartbeat 0(default) - The FE should not generate any Heartbeat
messages. In this scenario, the CE is responsible for messages. In this scenario, the CE is responsible for
checking FE liveness by setting the PL header ACK flag of checking FE liveness by setting the PL header ACK flag of
the message it sends to AlwaysACK. The FE responds to CE the message it sends to AlwaysACK. The FE responds to CE
whenever CE sends such Heartbeat Request Message. Refer to whenever CE sends such Heartbeat Request Message. Refer to
Section 7.9 and Section 4.3.2 for details. Section 7.9 and Section 4.3.3 for details.
1 - This policy specifies that FE must actively send a 1 - This policy specifies that FE must actively send a
Heartbeat Message if it reaches the time interval assigned Heartbeat Message if it reaches the time interval assigned
by the FE HI as long as no other messages were sent from FE 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.2. to CE during that interval as described in Section 4.3.3.
Others - Reserved. Others - Reserved.
* FE Heartbeat Interval (FE HI) - The time interval the FE should * FE Heartbeat Interval (FE HI) - The time interval the FE should
use to send HB as long as no other messages were sent from FE use to send HB as long as no other messages were sent from FE
to CE during that interval as described in Section 4.3.2. The to CE during that interval as described in Section 4.3.3. The
default value for an FE HI is 500ms. default value for an FE HI is 500ms.
* Primary CEID - The CEID that the FE is associated with. * Primary CEID - The CEID that the FE is associated with.
* Backup CEs - The list of backup CEs an FE is associated with. * Backup CEs - The list of backup CEs an FE is associated with.
Refer to Section 9 for details. Refer to Section 9 for details.
* FE restart policy - This specifies the behavior of the FE * FE restart policy - This specifies the behavior of the FE
during an FE restart. The restart may be from an FE failure or 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. other reasons that have made FE down and then need to restart.
skipping to change at page 49, line 29 skipping to change at page 50, line 33
The Operation TLV for event notificationis is defined below. The Operation TLV for event notificationis is defined below.
Operation TLV for Association Setup: Operation TLV for Association Setup:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
skipping to change at page 50, line 22 skipping to change at page 51, line 22
| | | |
| +-- LFBInstance = 0x1 | +-- LFBInstance = 0x1
| | | |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
| |
| |
+-- LFBInstance = 0x1 +-- LFBInstance = 0x1
| |
+-- Path-data to one or more attibutes +-- Path-data to one or more attributes
including suggested HB parameters including suggested HB parameters
Figure 17: PDU Format Figure 19: PDU Format
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
skipping to change at page 51, line 12 skipping to change at page 52, line 12
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
Type (16 bits): Type (16 bits):
The type of the TLV is "ASRresult". The type of the TLV is "ASRresult".
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:
skipping to change at page 51, line 42 skipping to change at page 52, line 44
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 reciever. 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
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.
Teardonw 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.
0 - normal teardown by administrator 0 - normal teardown by administrator
1 - error - loss of heartbeats 1 - error - loss of heartbeats
2 - error - out of bandwidth 2 - error - out of bandwidth
3 - error - out of memory 3 - error - out of memory
skipping to change at page 53, line 35 skipping to change at page 54, line 35
LFB select TLV is defined below. LFB select TLV is defined below.
Operation TLV for Config: Operation TLV for Config:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = "DEL" --- this operation to delete some LFB
attributes attributes
PATH-DATA-TLV: PATH-DATA-TLV:
skipping to change at page 54, line 32 skipping to change at page 55, line 34
| | | |
| +-- T = operation { SET } | +-- T = operation { SET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // associated with FULL or SPARSEDATA TLV(s) | | // associated with FULL or SPARSEDATA TLV(s)
| | | |
| +-- T = operation { DEL } | +-- T = operation { DEL }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
Figure 23: PDU Format
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
skipping to change at page 55, line 18 skipping to change at page 56, line 22
LFB select TLV is defined below. LFB select TLV is defined below.
Operation TLV for Config Response: Operation TLV for Config Response:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Operation TLV for Config Response
Type: Type:
The operation type for config response message. Two types of The operation type for config response message. Two types of
operations for the config response message are defined: operations for the config response message are defined:
Type = "SET-RESPONSE" --- this operation is for the Type = "SET-RESPONSE" --- this operation is for the
response of SET operation of LFB attributes response of SET operation of LFB attributes
Type = "DEL-RESPONSE" --- this operation is for the Type = "DEL-RESPONSE" --- this operation is for the
response of the DELETE operation of LFB attributes response of the DELETE operation of LFB attributes
skipping to change at page 56, line 28 skipping to change at page 57, line 34
LFB select TLV is defined below. LFB select TLV is defined below.
Operation TLV for Query: Operation TLV for Query:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET | Length | | Type = GET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET | | PATH-DATA-TLV for GET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: TLV for Query Figure 25: TLV for Query
Type: Type:
The operation type for query. One operation type is defined: The operation type for query. One operation type is 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: PATH-DATA-TLV for GET:
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
skipping to change at page 57, line 25 skipping to change at page 58, line 25
| | | |
| +-- T = operation { GET } | +-- T = operation { GET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | | |
| +-- T = operation { GET } | +-- T = operation { GET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | | |
Figure 24 Figure 26: 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.
skipping to change at page 58, line 18 skipping to change at page 59, line 18
in the LFB select TLV is defined below. in the LFB select TLV is defined below.
Operation TLV for Query Response: Operation TLV for Query Response:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET-RESPONSE | Length | | Type = GET-RESPONSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE | | PATH-DATA-TLV for GET-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: TLV for Query Response Figure 27: 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: PATH-DATA-TLV for GET-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
skipping to change at page 59, line 29 skipping to change at page 60, line 29
TLV in the LFB select TLV is defined below. TLV in the LFB select TLV is defined below.
Operation TLV for Event Notification: Operation TLV 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
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
skipping to change at page 60, line 25 skipping to change at page 61, line 25
| | | |
| +-- T = operation { REPORT } | +-- T = operation { REPORT }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // associated with FULL/SPARSE DATA TLV(s) | | // associated with FULL/SPARSE DATA TLV(s)
| +-- T = operation { REPORT } | +-- T = operation { REPORT }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // associated with FULL/SPARSE DATA TLV(s) | | // associated with FULL/SPARSE DATA TLV(s)
Figure 27: PDU Format Figure 29: PDU Format
7.8. Packet Redirect Message 7.8. Packet Redirect Message
Packet redirect message is used to transfer data packets between CE 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 IP packets, though they may
sometimes be associated with some metadata generated by other LFBs in sometimes be associated with some metadata generated by other LFBs in
the model. They may also occasionally be other protocol packets, the model. They may also occasionally be other protocol packets,
which usually happens when CE and FE are jointly implementing some which usually happens when CE and FE are jointly implementing some
high-touch operations. Packets redirected from FE to CE are the data 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 come from forwarding plane, and usually are the data
skipping to change at page 61, line 39 skipping to change at page 62, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV | | Meta Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV | | Redirect Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Redirect_Data TLV Figure 30: Redirect_Data TLV
LFB class ID: LFB class ID:
There are only two possible LFB classes here, the 'RedirectSink' There are only two possible LFB classes here, the 'RedirectSink'
LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from
FE to CE, the LFB class should be 'RedirectSink'. If the message FE to CE, the LFB class should be 'RedirectSink'. If the message
is from CE to FE, the LFB class should be 'RedirectSource'. is from CE to FE, the LFB class should be 'RedirectSource'.
Instance ID: Instance ID:
Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB.
skipping to change at page 62, line 21 skipping to change at page 63, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Redirected_Data TLV Figure 31: Redirected_Data 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
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. This actually implies
a Meta Data ID transcoding mechanism may be necessary if a a Meta Data ID transcoding mechanism may be necessary if a
metadata traverses several LFBs while these LFBs define the metadata traverses several LFBs while these LFBs define the
metadata with different Meta Data IDs. metadata with different Meta Data IDs.
Usually there are two meta data that are necessary for CE-FE Usually there are two meta data that are necessary for CE-FE
redirect operation. One is the redirected data type (e.g., IP redirect operation. One is the redirected data type (e.g., IP
packet, TCP packet, or UDP Packet). For an FE->CE redirect packet, TCP packet, or UDP Packet). For an FE->CE redirect
operation, redirected packet type meta data is usually a meta data operation, redirected packet type meta data is usually a meta data
specified by a Classifier LFB that filter out redirected packets specified by a Classifier LFB that filter out redirected packets
from packet stream and sends the packets to Redirect Sink LFB. from packet stream and sends the packets to Redirect Sink LFB.
For an CE->FE redirect operation, the redirected packet type meta For an CE->FE redirect operation, the redirected packet type meta
data is usually directly generated by CE. data is usually directly generated by CE.
Another meta data that should be associated with redirected data Another meta data that should be associated with redirected data
is the port number in a redirect LFB. For a RedirectSink LFB, the 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 port number meta data tells CE from which port in the lFB the
redirected data come. For a RedriectSource LFB, via the meta redirected data come. For a RedirectSource LFB, via the meta
data, CE tells FE which port in the LFB the redirected data should data, CE tells FE which port in the LFB the redirected data should
go out. 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
Redirected Data: Redirected Data:
This field presents the whole packet that is to be redirected. This field presents the whole packet that is to be redirected.
The packet should be 32bits aligned. The packet should be 32bits aligned.
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.
skipping to change at page 63, line 44 skipping to change at page 64, line 48
via a config message. The Heartbeat message is a little different via a config message. The Heartbeat message is a little different
from other protocol messages in that it is only composed of a common from other protocol messages in that it is only composed of a common
header, with the message body left empty. Detailed description of header, with the message body left empty. Detailed description of
the message is as below. 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.2 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. When set to 'AlwaysACK', the HB 'AlwaysACK' when the HB is sent.
Message sender is always expecting a response from its receiver.
When a response is sent it is always an echo of the original * When set to 'NoACK', the HB is not soliciting for a response.
message with reversed IDs and the ACK information set to 'NoACK'.
When not soliciting for response(default behavior), the ACK flag * When set to 'AlwaysACK', the HB Message sender is always
is set to 'NoACK' The correlator field in the HB message header expecting a response from its receiver. According the HB
must be set accordingly when a response is expected so that a policies defined in Section 7.2.1, only the CE can send such
receiver can correlate the response correctly. The correlator a HB message to query FE liveness. For simplicity and
field can be ignored if no response is expected. Also note that because of the minimal nature of the HB message, the response
by virtue of Heartbeat policies defined in Section 7.2.1 only CE to a HB message is another HB message, i.e. no specific HB
can send a HB Message with a response request. response message is defined. Whenever an FE receives a HB
message marked with 'AlwaysACK' from the CE, the FE MUST send
a HB message back immediately. The HB message sent by the FE
in response to the 'AlwasyACK' MUST modify the source 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 ACK information to 'NoACK'. A CE MUST NOT respond to an
HB message with 'AlwasyACK' set.
The correlator field in the HB message header SHOULD be set
accordingly when a response is expected so that a receiver can
correlate the response correctly. The correlator field MAY be
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 7.10. Operation Summary
The following table summarizes the TLVs that compose messages, and The following table summarizes the TLVs that compose messages, and
the applicabiity of operation TLVs to the messages. the applicabiity of operation TLVs to the messages.
+---------------------------+-----------+---------------------------+ +---------------------------+-----------+---------------------------+
skipping to change at page 67, line 36 skipping to change at page 69, line 36
| Config FEO Adminup | | Config FEO Adminup |
|<----------------------| |<----------------------|
| | | |
| FEO Config-Resp | | FEO Config-Resp |
|---------------------->| |---------------------->|
| | | |
| FEO UP Event | | FEO UP Event |
|---------------------->| |---------------------->|
| | | |
Figure 32: Message exchange between CE and FE to establish an NE Figure 34: Message exchange between CE and FE to establish an NE
association association
On successful completion of this state, the FE joins the NE. On successful completion of this state, the FE joins the NE.
8.2. Association Established state or Steady State 8.2. Association Established state or Steady State
In this state the FE is continously updated or queried. The FE may In this state the FE is continously 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 messages. This continues until a termination (or heartbeat messages. This continues until a termination (or
deactivation) is initiated by either the CE or FE. The figure below deactivation) is initiated by either the CE or FE. The figure below
skipping to change at page 68, line 50 skipping to change at page 70, line 50
| | | |
| Packet Redirect LFBx | | Packet Redirect LFBx |
|----------------------------->| |----------------------------->|
| | | |
| Heart Beat | | Heart Beat |
|<-----------------------------| |<-----------------------------|
. . . .
. . . .
| | | |
Figure 33: Message exchange between CE and FE during steady-state Figure 35: Message exchange between CE and FE during steady-state
communication communication
Note that the sequence of messages shown in the figure serve only as Note that the sequence of messages shown in the figure serve only as
examples and the messages exchange sequences could be different from examples and the messages exchange sequences could be different from
what is shown in the figure. Also, note that the protocol scenarios what is shown in the figure. Also, note that the protocol scenarios
described in this section do not include all the different message described in this section do not include all the different message
exchanges which would take place during failover. That is described exchanges which would take place during failover. That is described
in the HA section 8. in the HA section 8.
9. High Availability Support 9. High Availability Support
skipping to change at page 70, line 18 skipping to change at page 72, line 18
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 draft. There can be multiple redundant CEs and FEs
in a ForCES NE. However, at any one time only one Primary CE can 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 are defined in the ForCES protocol, Report Primary Mode and Two HA modes are defined in the ForCES protocol, Report Primary Mode
Report All Mode. The Report Primary Mode is the default mode of the and Report All Mode. The Report Primary Mode is the default mode of
protocol, in which the FEs only associate with one CE (primary) at a the protocol, in which the FEs only associate with one CE (primary)
time. The Report All mode is for future study and not part of the at a time. The Report All mode is for future study and not part of
current protocol version. In this mode, the FE would establish the current protocol version. In this mode, the FE would establish
association with multiple CEs (primary and secondary) and report association with multiple CEs (primary and secondary) and report
events, packets, Heart Beats to all the CEs. However, only the events, packets, Heart Beats to all the CEs. However, only the
primary CE would configure/control the FE in this mode as well. This primary CE would configure/control the FE in this mode as well. This
helps with keeping state between CEs synchronized, although it does would help with keeping state between CEs synchronized, although it
not guarantee synchronization. would not guarantee synchronization.
The HA Modes are configured during Association setup phase, currently The HA Modes are configured during Association setup phase, though
only Report Primary Mode is configured. A CE-to-CE synchronization currently only Report Primary Mode can be configured. A CE-to-CE
protocol will be needed to support fast failover as well as address synchronization protocol would be needed to support fast failover as
some of the corner cases, however this will not be defined by the well as address some of the corner cases, however this will not be
ForCES protocol (since it is out of scope). defined by the ForCES protocol as it is out of scope for this
specification.
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), the TML on the FE due to CE or link reasons, i.e. not FE related), either the TML on
will trigger the FE PL regarding this failure. This can also 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 (detected via either of the two means described communication failure, regardless of how it is detected, MUST be
before) is considered as a loss of association between the CE and considered as a loss of association between the CE and corresponding
corresponding FE and the FE PL must establish association with the FE. In the Report Primary mode, as there should be no other existing
secondary CE at this point. During this phase, if the original CE-FE associations, the FE PL MUST at this point establish
primary CE comes alive and starts sending any commands to the FE, the association with the secondary CE. Once the process has started, if
FE should ignore those messages and send an Event to all CEs the original primary CE comes alive and starts sending commands
indicating its change in Primary CE. Thus the FE only has one message to the FE, the FE MUST ignore those messages. If the
primary CE at a time. 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 An explicit message (Config message setting Primary CE attribute in
ForCES Protocol object) from the primary CE, can also be used to ForCES Protocol object) from the primary CE, can also be used to
change the Primary CE for an FE during normal protocol operation. change the Primary CE for an FE during normal protocol operation.
Also note that the FEs in a ForCES NE could also use a multicast Also note that the FEs in a ForCES NE could also use a multicast
CEID, i.e. they are associated with a group of CEs (assumes some form CEID, i.e. they are associated with a group of CEs (this assumes the
of CE-CE synchronization protocol). In this case the loss of use of a CE-CE synchronization protocol, which is out of scope for
association would mean that communication with the entire multicast this specification). In this case the loss of association would mean
group of CEs has been lost. The mechanisms described above will that communication with the entire multicast group of CEs has been
apply for this case as well during the loss of association. 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 CEID that was lost, then the FE will
need to form a new association using a different CEID. If the
capability exists, the FE MAY first attempt to form a new association
with original primary CE using a different non multicast CEID.
These two scenarios (Report All, Report Primary) have been These two scenarios, Report Primary (default), Report Primary
illustrated in the figures below. (currently unsupported), are illustrated in the Figure 36 and
Figure 37 below.
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| Asso Estb,Caps|exchange |
2 |<----------------------|------------------->|
| | |
| All msgs | | | All msgs | |
3 |<--------------------->| | 2 |<--------------------->| |
| | | | | |
| packet redirection,|events, HBs |
4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 4 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |<------------------------------------------>| 5 |<------------------------------------------>|
Figure 34: CE Failover for Report All mode Figure 36: CE Failover for Report Primary Mode
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| Asso Estb,Caps|exchange |
2 |<----------------------|------------------->|
| | |
| All msgs | | | All msgs | |
2 |<--------------------->| | 3 |<--------------------->| |
| | | | | |
| packet redirection,|events, HBs |
4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) | | Event Report (pri CE down) |
4 |------------------------------------------->| 5 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
5 |<------------------------------------------>| 6 |<------------------------------------------>|
Figure 35: CE Failover for Report Primary Mode Figure 37: CE Failover for Report All mode
9.1. Responsibilities for HA 9.1. Responsibilities for HA
TML level - Transport level: TML level - Transport 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
skipping to change at page 76, line 8 skipping to change at page 79, line 8
For details refer to Section 5. For details refer to Section 5.
10.2.3. Confidentiality service 10.2.3. Confidentiality service
This is TML specific operation and is transparent to ForCES PL layer. This is TML specific operation and is transparent to ForCES PL layer.
For details refer to Section 5. For details refer to Section 5.
11. Acknowledgments 11. 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
following: Alex Audu, Steven Blake, Alan DeKok, Ellen M. Deleganes, ForCES Working Group and especially the following: Furquan Ansari,
Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, Alex Audu, Steven Blake, Shuchi Chawla Alan DeKok, Ellen M.
Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M.
their contributions. We would also like to thank David Putzolu, and Halpern (who should probably be listed among the authors), Zsolt
Patrick Droz for their comments and suggestions on the protocol. Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering,
T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their
contributions. We would also like to thank David Putzolu, and
Patrick Droz for their comments and suggestions on the protocol and
for their infinite patience.
12. References 12. References
12.1. Normative References 12.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.
skipping to change at page 78, line 38 skipping to change at page 81, line 38
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:
0x00 ............... Heartbeat 0x00 ............... Reserved
0x01 ............... Association Messages 0x01 ............... AssociationSetup
0x02 ............... Configuration Messages 0x02 ............... AssociationTeardown
0x03 ............... Query Messages 0x03 ............... Config
0x04 ............... Event Notifications 0x04 ............... Query
0x05 ............... Packet Redirection 0x05 ............... EventNotification
0x06 ............... PacketRedirect
Message Types 0x10 - 0x7F 0x07 - 0x0E ........ Reserved
0x0F ............... Hearbeat
0x11 ............... AssociationSetupRepsonse
0x12 ............... Reserved
0x13 ............... ConfigRepsonse
0x14 ............... QueryResponse
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 references.
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.
skipping to change at page 79, line 44 skipping to change at page 82, line 48
Operation Type 0x8000-0xFFFF Operation Type 0x8000-0xFFFF
Operation Types in this range are reserved for vendor private Operation 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 Operation 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 the
ForCES base protocol. Header flags are allocated through an IETF ForCES base protocol. Header flags are allocated through an IETF
consensus action [RFC2434]. TLV Result Values in this range are consensus action [RFC2434].
allocated through an IETF consensus process. [RFC2434].
Values assigned by this specification:
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:
skipping to change at page 80, line 34 skipping to change at page 83, line 39
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 references. [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. LFB Class Id Name Space A.5. LFB Class Id Name Space
The LFB Class ID name space is 32 bits long. The following iws the The LFB Class ID name space is 32 bits long. The following is the
guideline for managing the TLV Result Name Space. guideline for managing the TLV Result Name Space.
LFB Class ID 0x00000000-0x0000FFFF LFB Class ID 0x00000000-0x0000FFFF
LFB Class IDs in this range are allocated through an IETF LFB Class IDs in this range are allocated through an IETF
consensus process. [RFC2434]. consensus process. [RFC2434].
Values assigned by this specification: Values assigned by this specification:
0x00000000 Reserved 0x00000000 Reserved
0x00000001 FE Protocol LFB 0x00000001 FE Protocol LFB
0x00000002 FE Object LFB 0x00000002 FE Object LFB
skipping to change at page 81, line 21 skipping to change at page 84, line 25
The Association Setup Response name space is 16 bits long. The The Association Setup Response name space is 16 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 this specification: Values assigned by this specification:
0x0000 Succcess 0x0000 Success
0x0001 FE ID Invalid 0x0001 FE ID Invalid
0x0002 Too many associations 0x0002 Too many associations
0x0003 Permission Denied 0x0003 Permission Denied
Association Setup Response 0x0100-0x0FFF Association Setup Response 0x0100-0x0FFF
Association Setup Responses in this range are Specification Association Setup Responses in this range are Specification
Required [RFC2434] Values using this range must be documented in Required [RFC2434] Values using this range must be documented in
an RFC or other permanent and readily available references. an RFC or other permanent and readily available references.
[RFC2434]. [RFC2434].
skipping to change at page 94, line 10 skipping to change at page 97, line 10
x2, ID2 , type u32 x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1} KEY: tkey, ID = 1, V = { x1}
All examples will show an attribute suffixed with "v" or "val" to All examples will show an attribute suffixed with "v" or "val" to
indicate the value of the referenced attribute. example for attribute indicate the value of the referenced attribute. example for attribute
foo2, foo1v or foo1value will indicate the value of foo1. In the foo2, foo1v or foo1value will indicate the value of foo1. In the
case where F_SEL** are missing (bits equal to 00) then the flags will case where F_SEL** are missing (bits equal to 00) then the flags will
not show any selection. not show any selection.
All the examples only show use of FULLDATA for data encoding; All the examples only show use of FULLDATA for data encoding;
although SPARSEDATA would make more sense in certain occassions, the although SPARSEDATA would make more sense in certain occasions, the
emphasis is on showing the message layout. Refer to Appendix C for emphasis is on showing the message layout. Refer to Appendix C for
examples that show usage of both FULLDATA and SPARSEDATA. examples that show usage of both FULLDATA and SPARSEDATA.
1. To get foo1 1. To get foo1
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: IDCount = 1, IDs = 1 Path-data TLV: IDCount = 1, IDs = 1
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
skipping to change at page 95, line 4 skipping to change at page 98, line 4
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
IDCount = 1, IDs = 4 IDCount = 1, IDs = 4
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
FULLDATA=TLV: L = XXX, V= FULLDATA=TLV: L = XXX, V=
a series of: index, j1value,j2value entries a series of: index, j1value,j2value entries
representing the entire table representing the entire table
4. Note: One should be able to take a GET-RESPONSE-TLV and convert Note: One should be able to take a GET-RESPONSE-TLV and convert
it to a SET-REPLACE-TLV. If the result in the above example is it to a SET-REPLACE-TLV. If the result in the above example
sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) is sent back in a SET-REPLACE-TLV, (instead of a GET-
then the entire contents of the table will be replaced at that RESPONSE_TLV) then the entire contents of the table will be
point. replaced at that point.
4. Multiple operations Example. To create entry 0-5 of table2
(Error conditions are ignored)
5. Multiple operations Example. To create entry 0-5 of table2
(Ignore error conditions for now)
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing j1, j2 value for entry 0 FULLDATA-TLV containing j1, j2 value for entry 0
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA-TLV containing j1, j2 value for entry 1 FULLDATA-TLV containing j1, j2 value for entry 1
PATH-DATA-TLV PATH-DATA-TLV
skipping to change at page 97, line 4 skipping to change at page 99, line 26
RESULT-TLV RESULT-TLV
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
RESULT-TLV RESULT-TLV
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
RESULT-TLV RESULT-TLV
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
RESULT-TLV RESULT-TLV
6. Block operations (with holes) example. Replace entry 0,2 of
5. Block operations (with holes) example. Replace entry 0,2 of
table2 table2
OPER = SET-REPLACE-TLV OPER = SET-REPLACE-TLV
Path-data TLV: Path-data TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
FULLDATA-TLV containing j1, j2 value for entry 0 FULLDATA-TLV containing j1, j2 value for entry 0
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
skipping to change at page 97, line 27 skipping to change at page 100, line 4
Result: Result:
OPER = SET-REPLACE-TLV OPER = SET-REPLACE-TLV
Path-data TLV: Path-data TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
RESULT-TLV RESULT-TLV
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
RESULT-TLV RESULT-TLV
6. Getting rows example. Get first entry of table2.
7. Getting rows example. Get first entry of table2.
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: Path-data TLV:
IDCount = 2, IDs=4.0 IDCount = 2, IDs=4.0
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
IDCount = 2, IDs=4.0 IDCount = 2, IDs=4.0
FULLDATA TLV, Length = XXX, V = FULLDATA TLV, Length = XXX, V =
j1value,j2value entry j1value,j2value entry
8. Get entry 0-5 of table2. 7. Get entry 0-5 of table2.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs=4 flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
skipping to change at page 98, line 44 skipping to change at page 101, line 44
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
FULLDATA-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
FULLDATA-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
FULLDATA-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
9. Create a row in table2, index 5. 8. Create a row in table2, index 5.
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 2, IDs=4.5 flags = 0, IDCount = 2, IDs=4.5
FULLDATA TLV, Length = XXX FULLDATA TLV, Length = XXX
j1value,j2value j1value,j2value
Result: Result:
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=4.5 flags = 0, IDCount = 1, IDs=4.5
RESULT-TLV RESULT-TLV
10. An example of "create and give me an index" Assuming one asked 9. An example of "create and give me an index" Assuming one asked
for verbose response back in the main message header. for verbose response back in the main message header.
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data -TLV: Path-data -TLV:
flags = FIND-EMPTY, IDCount = 1, IDs=4 flags = FIND-EMPTY, IDCount = 1, IDs=4
FULLDATA TLV, Length = XXX FULLDATA TLV, Length = XXX
j1value,j2value j1value,j2value
Result Result
If 7 were the first unused entry in the table: If 7 were the first unused entry in the table:
OPER = SET-RESPONSE OPER = SET-RESPONSE
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 2, IDs=4.7 flags = 0, IDCount = 2, IDs=4.7
RESULT-TLV indicating success, and RESULT-TLV indicating success, and
FULLDATA-TLV, Length = XXX j1value,j2value FULLDATA-TLV, Length = XXX j1value,j2value
11. Dump contents of table1. 10. Dump contents of table1.
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=3 flags = 0, IDCount = 1, IDs=3
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs=3 flags = 0, IDCount = 1, IDs=3
FULLDATA TLV, Length = XXXX FULLDATA TLV, Length = XXXX
(depending on size of table1) (depending on size of table1)
index, t1value, t2value index, t1value, t2value
index, t1value, t2value index, t1value, t2value
. .
. .
. .
12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 11. Using Keys. Get row entry from table4 where j1=100. Recall, j1
is a defined key for this table and its keyid is 1. is a defined key for this table and its keyid is 1.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = F_SELKEY IDCount = 1, IDs=6 flags = F_SELKEY IDCount = 1, IDs=6
KEYINFO-TLV = KEYID=1, KEY_DATA=100 KEYINFO-TLV = KEYID=1, KEY_DATA=100
Result: Result:
If j1=100 was at index 10 If j1=100 was at index 10
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=6.10 flags = 0, IDCount = 1, IDs=6.10
FULLDATA TLV, Length = XXXX FULLDATA TLV, Length = XXXX
j1value,j2value, j3value, j4value j1value,j2value, j3value, j4value
13. Delete row with KEY match (j1=100, j2=200) in table 2. Note 12. Delete row with KEY match (j1=100, j2=200) in table 2. Note
that the j1,j2 pair are a defined key for the table 2. that the j1,j2 pair are a defined key for the table 2.
OPER = DEL-TLV OPER = DEL-TLV
Path-data TLV: Path-data TLV:
flags = F_SELKEY IDCount = 1, IDs=4 flags = F_SELKEY IDCount = 1, IDs=4
KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} KEYINFO TLV: {KEYID =1 KEY_DATA=100,200}
Result: Result:
If (j1=100, j2=200) was at entry 15: If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV OPER = DELETE-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0 IDCount = 2, IDs=4.15 flags = 0 IDCount = 2, IDs=4.15
RESULT-TLV (with FULLDATA if verbose) RESULT-TLV (with FULLDATA if verbose)
14. Dump contents of table3. It should be noted that this table has 13. Dump contents of table3. It should be noted that this table has
a column with element name that is variable sized. The purpose a column with element name that is variable sized. The purpose
of this use case is to show how such an element is to be of this use case is to show how such an element is to be
encoded. encoded.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = 0 IDCount = 1, IDs=5 flags = 0 IDCount = 1, IDs=5
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
skipping to change at page 101, line 26 skipping to change at page 104, line 26
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
. .
. .
. .
15. Multiple atomic operations. 14. Multiple atomic operations.
16. Note: This emulates adding a new nexthop entry and then Note 1: This emulates adding a new nexthop entry and then
atomically updating the L3 entries pointing to an old NH to atomically updating the L3 entries pointing to an old NH to
point to a new one. The assumption is both tables are in the point to a new one. The assumption is both tables are in the
same LFB same LFB
17. Main header has atomic flag set and the request is for verbose/ Note2: Main header has atomic flag set and the request is for
full results back; Two operations on the LFB instance, both are verbose/full results back; Two operations on the LFB
SET operations. instance, both are SET operations.
//Operation 1: Add a new entry to table2 index #20. //Operation 1: Add a new entry to table2 index #20.
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-TLV: Path-TLV:
flags = 0, IDCount = 2, IDs=4.20 flags = 0, IDCount = 2, IDs=4.20
FULLDATA TLV, V= j1value,j2value FULLDATA TLV, V= j1value,j2value
// Operation 2: Update table1 entry which // Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20 // was pointing with t2 = 10 to now point to 20
OPER = SET-REPLACE-TLV OPER = SET-REPLACE-TLV
skipping to change at page 102, line 46 skipping to change at page 105, line 46
// second opertion SET // second opertion SET
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data TLV Path-data TLV
flags = 0 IDCount = 1, IDs=3 flags = 0 IDCount = 1, IDs=3
KEYINFO = KEYID=1 KEY_DATA=10 KEYINFO = KEYID=1 KEY_DATA=10
Path-Data TLV Path-Data TLV
flags = 0 IDCount = 1, IDs = 2 flags = 0 IDCount = 1, IDs = 2
SET-RESULT-TLV code = success SET-RESULT-TLV code = success
FULLDATA TLV, Length = XXXX v=20 FULLDATA TLV, Length = XXXX v=20
18. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 15. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9.
Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is.
PER = SET-REPLACE-TLV PER = SET-REPLACE-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 6 flags = 0, IDCount = 1, IDs = 6
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA TLV, Length = XXXX, V = {100} FULLDATA TLV, Length = XXXX, V = {100}
skipping to change at page 105, line 27 skipping to change at page 108, line 27
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
RESULT-TLV RESULT-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
RESULT-TLV RESULT-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
RESULT-TLV RESULT-TLV
19. Manipulation of table of table examples. Get x1 from table10 16. Manipulation of table of table examples. Get x1 from table10
row with index 4, inside table5 entry 10 row with index 4, inside table5 entry 10
operation = GET-TLV operation = GET-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1 flags = 0 IDCount = 5, IDs=7.10.2.4.1
Results: Results:
operation = GET-RESPONSE-TLV operation = GET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1 flags = 0 IDCount = 5, IDs=7.10.2.4.1
FULLDATA TLV: L=XXXX, V = {x1 value} FULLDATA TLV: L=XXXX, V = {x1 value}
20. From table5's row 10 table10, get X2s based on on the value of 17. From table5's row 10 table10, get X2s based on on the value of
x1 equlaing 10 (recal x1 is KeyID 1) x1 equaling 10 (recall x1 is KeyID 1)
operation = GET-TLV operation = GET-TLV
Path-data-TLV Path-data-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2 flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO TLV, KEYID = 1, KEYDATA = 10 KEYINFO TLV, KEYID = 1, KEYDATA = 10
Path-data TLV Path-data TLV
IDCount = 1, IDS = 2 //select x2 IDCount = 1, IDS = 2 //select x2
Results: Results:
If x1=10 was at entry 11: If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV operation = GET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11 flag = 0, IDCount=5, IDS = 7.10.2.11
Path-data TLV Path-data TLV
flags = 0 IDCount = 1, IDS = 2 flags = 0 IDCount = 1, IDS = 2
FULLDATA TLV: L=XXXX, V = {x2 value} FULLDATA TLV: L=XXXX, V = {x2 value}
21. Further example of table of table 18. Further example of manipulating a table of tables
Consider table 6 which is defined as: Consider table 6 which is defined as:
table6: type array, ID = 8 table6: type array, ID = 8
elements are: elements are:
p1, type u32, ID = 1 p1, type u32, ID = 1
p2, type array, ID = 2, array elements of type type-A p2, type array, ID = 2, array elements of type type-A
type-A: type-A:
a1, type u32, ID 1, a1, type u32, ID 1,
a2, type array ID2 ,array elements of type type-B a2, type array ID2 ,array elements of type type-B
skipping to change at page 106, line 45 skipping to change at page 109, line 45
If for example one wanted to set by replacing: If for example one wanted to set by replacing:
table6.10.p1 to 111 table6.10.p1 to 111
table6.10.p2.20.a1 to 222 table6.10.p2.20.a1 to 222
table6.10.p2.20.a2.30.b1 to 333 table6.10.p2.20.a2.30.b1 to 333
in one message and one operation. in one message and one operation.
There are two ways to do this: There are two ways to do this:
a) using nesting a) using nesting
b) using a flat path data
A. Method using nesting
in one message with a single operation
operation = SET-REPLACE-TLV operation = SET-REPLACE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10 flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV Path-data-TLV
flags = 0, IDCount = 1, IDs=1 flags = 0, IDCount = 1, IDs=1
FULLDATA TLV: L=XXXX, FULLDATA TLV: L=XXXX,
V = {111} V = {111}
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20 flags = 0 IDCount = 2, IDs=2.20
skipping to change at page 107, line 32 skipping to change at page 111, line 4
flags = 0, IDCount = 1, IDs=1 flags = 0, IDCount = 1, IDs=1
RESULT-TLV RESULT-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20 flags = 0 IDCount = 2, IDs=2.20
Path-data-TLV Path-data-TLV
flags = 0, IDCount = 1, IDs=1 flags = 0, IDCount = 1, IDs=1
RESULT-TLV RESULT-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1 flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV RESULT-TLV
b) using a flat path data B. Method using a flat path data in
one message with a single operation
operation = SET-REPLACE-TLV operation = SET-REPLACE-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1 flags = 0, IDCount = 3, IDs=6.10.1
FULLDATA TLV: L=XXXX, FULLDATA TLV: L=XXXX,
V = {111} V = {111}
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1 flags = 0, IDCount = 5, IDs=6.10.1.20.1
FULLDATA TLV: L=XXXX, FULLDATA TLV: L=XXXX,
V = {222} V = {222}
Path-data TLV : Path-data TLV :
skipping to change at page 108, line 4 skipping to change at page 111, line 26
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
FULLDATA TLV: L=XXXX, FULLDATA TLV: L=XXXX,
V = {333} V = {333}
Result: Result:
operation = SET-REPLACE-TLV operation = SET-REPLACE-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1 flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV RESULT-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1 flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV RESULT-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV RESULT-TLV
22. Get a whole LFB (all its attributes, etc.). 19. Get a whole LFB (all its attributes, etc.).
23. For example, at startup a CE might well want the entire FE For example: at startup a CE might well want the entire FE
OBJECT LFB. So, in a request targetted at class 1, instance 1, OBJECT LFB. So, in a request targeted at class 1, instance
one might find: 1, one might find:
operation = GET-TLV operation = GET-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 0 flags = 0 IDCount = 0
result: result:
operation = GET-RESPONSE-TLV operation = GET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 0 flags = 0 IDCount = 0
FULLDATA encoding of the FE Object LFB FULLDATA encoding of the FE Object LFB
Appendix E. Changes between -05 and -06; Post WGLC Authors' Addresses
Note: This section should be removed by the RFC editor prior to
publication
Changes raised by issue tracker:
o 09: Fixed LFB Definitions
o 39: No Substantive Change. Some text clarification.
o 62: Fixed FE Protocol LFB xml
o 63: Nits fixed
o 64: Editorial changes made. Second author's section removed.
o 65: No change. saying the protocl makes extensive use does not
preclude that this is becasue all info is exchange in TLV/ILV.
Since this was an introduction did not want to go into greater
detail.
o 66: Moved Model document to Normative references
o 67: Changed requirements level
o 68: Changed text on Repsonse requirements
o 69: Made requirements for top edge semantics a MUST
o 70: Made using the same correlator in response a MUST
o 71: Made requirement for a single FE Protocol LFB a MUST
o 72: Editorial fixes
o 73: NITS fixed. Spell Checker run.
o 74: Change some instances where value was ignored to be more
explicit. Not sure I caught them all. Some may still need
discussion.
o 75: NITS fixed
o 76: Fixed Editorials, accepted new wording, fixed CE/FE functions
picture, added ILV picture. Did not change any state diagrams.
o 77: Some clarification text added
o 78: Editorial changes made.
o 79: Added section on RFC2119 words.
o 80: Fixed reference to FE Object LFB and changes values to be
consistent
Other Changes
o Removed pre WGLC histories
o Added titles to some figures. Some more need to be done, but I am
having some trouble with the sml source (titles are in the source
but not showing up in the text)
o Added TLV list to IANA section
o Added Operations to IANA section Ligang Dong
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Authors' Addresses Phone: +86-571-88071024
Email: donglg@mail.zjgsu.edu.cn
Avri Doria Avri Doria
ETRI ETRI
Lulea University of Technology Lulea University of Technology
Lulea Lulea
Sweden Sweden
Phone: +46 73 277 1788 Phone: +46 73 277 1788
Email: avri@acm.org Email: avri@acm.org
Ram Gopal
Nokia
5, Wayside Road
Burlington, MA 310035
USA
Phone: +1-781-993-3685
Email: ram.gopal@nokia.com
Robert Haas Robert Haas
IBM IBM
Saumerstrasse 4 Saumerstrasse 4
8803 Ruschlikon 8803 Ruschlikon
Switzerland Switzerland
Phone: Phone:
Email: rha@zurich.ibm.com Email: rha@zurich.ibm.com
Jamal Hadi Salim Jamal Hadi Salim
Znyx Znyx
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Phone: Phone:
Email: hadi@znyx.com Email: hadi@znyx.com
Hormuzd M Khosravi Hormuzd M Khosravi
Intel Intel
skipping to change at page 113, line 41 skipping to change at page 114, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 192 change blocks. 
484 lines changed or deleted 575 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/