draft-ietf-forces-protocol-00.txt   draft-ietf-forces-protocol-01.txt 
Network Working Group A. Doria (co-editor) Network Working Group A. Doria (co-editor)
Internet-Draft ETRI Internet-Draft ETRI
Expires: March 26, 2005 September 25, 2004 Expires: April 25, 2005 October 25, 2004
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-00.txt draft-ietf-forces-protocol-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 March 26, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This specification documents the Forwarding and Control Element This specification documents the Forwarding and Control Element
Seperation protocol. This protocol is desgined to be used between a Separation protocol. This protocol is designed to be used between a
Control Element and a Forwarding Element in a Routing Network Control Element and a Forwarding Element in a Routing Network
Element. Element.
Authors Authors
The participants in the ForCES Protocol Team, authors and co-editors, The participants in the ForCES Protocol Team, co-authors and
of this draft, are: co-editors, of this draft, are:
Ligang Dong, Zhejiang Gongshang University
Avri Doria, ETRI
Ram Gopal, Nokia
Robert Haas, IBM
Jamal Hadi Salim, Znyx
Hormuzd M Khosravi, Intel
Weiming Wang, Zhejiang Gongshang University
Acknowledgment
The authors of this draft would like to acknowledge and thank all the Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram
protocol proposal authors including Alex Audu, Steven Blake, Chaoping Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M
Wu, Jeff Pickering, Yunfei Guo, and Guangming Wang for their Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University).
contributions. We would also like to thank David Putzolu, and
Patrick Droz for their comments and suggestions on the protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Sections of this document . . . . . . . . . . . . . . . . 5 1.1 Sections of this document . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 9 3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 8
3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 11 3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 12 3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 11
3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 12 3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 11
3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 13 3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 12
3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 13 3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 12
3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 14 3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 13
3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 15 3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 14
3.3.1 Of Transactions, Atomicity and 2 Phase Commits . . . . 15 3.3.1 Of Transactions, Atomicity and 2 Phase Commits . . . . 14
3.3.2 FE Protocol Object . . . . . . . . . . . . . . . . . . 15 3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . . 15
3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 16 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 15
4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 19 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 18
5. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 23 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 22
6.1 Association Messages . . . . . . . . . . . . . . . . . . . 23 6.1 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . . 22
6.1.1 Association Setup Message . . . . . . . . . . . . . . 23 6.1.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . . 23
6.1.2 Association Setup Response Message . . . . . . . . . . 24 6.1.2 FE LFB . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.3 Association Teardown Message . . . . . . . . . . . . . 25 6.1.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Query and Response Messages . . . . . . . . . . . . . . . 25 6.2 Association Messages . . . . . . . . . . . . . . . . . . . 25
6.2.1 Query Message . . . . . . . . . . . . . . . . . . . . 26 6.2.1 Association Setup Message . . . . . . . . . . . . . . 25
6.2.2 Query Response Message . . . . . . . . . . . . . . . . 29 6.2.2 Association Setup Response Message . . . . . . . . . . 27
6.3 Configuration Messages . . . . . . . . . . . . . . . . . . 31 6.2.3 Association Teardown Message . . . . . . . . . . . . . 29
6.3.1 Config Message . . . . . . . . . . . . . . . . . . . . 31 6.3 Configuration Messages . . . . . . . . . . . . . . . . . . 30
6.3.2 Config Response Message . . . . . . . . . . . . . . . 33 6.3.1 Config Message . . . . . . . . . . . . . . . . . . . . 30
6.4 Event Notification and Response Messages . . . . . . . . . 34 6.3.2 Config Response Message . . . . . . . . . . . . . . . 32
6.4.1 Event Notification Message . . . . . . . . . . . . . . 35 6.4 Query and Query Response Messages . . . . . . . . . . . . 34
6.4.2 Event Notification Response Message . . . . . . . . . 37 6.4.1 Query Message . . . . . . . . . . . . . . . . . . . . 34
6.5 Packet Redirect Message . . . . . . . . . . . . . . . . . 38 6.4.2 Query Response Message . . . . . . . . . . . . . . . . 36
6.6 State Maintenance Messages . . . . . . . . . . . . . . . . 42 6.5 Event Notification and Response Messages . . . . . . . . . 37
6.6.1 State Maintenance Message . . . . . . . . . . . . . . 42 6.5.1 Event Notification Message . . . . . . . . . . . . . . 38
6.6.2 State Maintenance Response Message . . . . . . . . . . 43 6.5.2 Event Notification Response Message . . . . . . . . . 40
6.7 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 44 6.6 Packet Redirect Message . . . . . . . . . . . . . . . . . 41
7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 45 6.7 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 45
7.1 Association Setup state . . . . . . . . . . . . . . . . . 45 6.8 Operation Summary . . . . . . . . . . . . . . . . . . . . 45
7.2 Association Established state or Steady State . . . . . . 46 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 47
8. High Availability Support . . . . . . . . . . . . . . . . . . 49 7.1 Association Setup state . . . . . . . . . . . . . . . . . 47
8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 51 7.2 Association Established state or Steady State . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8. High Availability Support . . . . . . . . . . . . . . . . . . 51
9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 52 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 53
9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 52 9. Security Considerations . . . . . . . . . . . . . . . . . . . 54
9.1.2 Message authentication . . . . . . . . . . . . . . . . 53 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 54
9.2 ForCES PL and TML security service . . . . . . . . . . . . 53 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 54
9.2.1 Endpoint authentication service . . . . . . . . . . . 53 9.1.2 Message authentication . . . . . . . . . . . . . . . . 55
9.2.2 Message authentication service . . . . . . . . . . . . 53 9.2 ForCES PL and TML security service . . . . . . . . . . . . 55
9.2.3 Confidentiality service . . . . . . . . . . . . . . . 54 9.2.1 Endpoint authentication service . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 55 9.2.2 Message authentication service . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.2.3 Confidentiality service . . . . . . . . . . . . . . . 56
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 55 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 57
10.2 Informational References . . . . . . . . . . . . . . . . . . 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 56 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 58
B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 57 11.2 Informational References . . . . . . . . . . . . . . . . . . 58
C. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 58
C.1 TML considerations . . . . . . . . . . . . . . . . . . . . 58 A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 59
C.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 58 B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 61
C.1.2 Message type inference to Mapping at the TML . . . . . 59 C. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . 60 C.1 TML considerations . . . . . . . . . . . . . . . . . . . . 62
C.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 62
C.1.2 Message type inference to Mapping at the TML . . . . . 63
D. Changes between -00 and -01 . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . . 65
1. Introduction 1. Introduction
This specification provides a draft definition of an IP-based This specification provides a draft definition of an IP-based
protocol for Control Element control of an Forwarding Element. The protocol for Control Element control of an Forwarding Element. The
protocol is a TLV based protocol that include commands for transport protocol is a TLV based protocol that include commands for transport
of LFB information as well as TLVs for association, configuration, of LFB information as well as TLVs for association, configuration,
status, and events. status, and events.
This specification does not specify a transport mechanism for This specification does not specify a transport mechanism for
skipping to change at page 6, line 7 skipping to change at page 5, line 7
Section 7 describes several Protocol Scenarios and includes message Section 7 describes several Protocol Scenarios and includes message
exchange descriptions. exchange descriptions.
Section 8 describes mechanism in the protocol to support high Section 8 describes mechanism in the protocol to support high
availability mechanisms including redundancy and fail over. Section availability mechanisms including redundancy and fail over. Section
9 defines the security mechanisms provided by the PL and TML. 9 defines the security mechanisms provided by the PL and TML.
2. Definitions 2. Definitions
This document follows the terminologies 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 terminologies defined by ForCES FE model This document also uses the terminology defined by ForCES FE model in
in [FE-MODEL]. We copy the definitions of some terminologies as [FE-MODEL]. We copy the definitions of some of the terminology as
below: indicated below:
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 to which we can communicate using an IP networks, it is a device to which we can communicate using an IP
address; and on a switch fabric, it is a device to which we can address; and on a switch fabric, it is a device to which we can
communicate using a switch fabric port number. communicate using a 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 8 skipping to change at page 8, line 8
ForCES protocol architecture that specifically addresses the protocol ForCES protocol architecture that specifically addresses the protocol
message transportation issues, such as how the protocol messages are message transportation issues, such as how the protocol messages are
mapped to different transport media (like TCP, IP, ATM, Ethernet, mapped to different transport media (like TCP, IP, ATM, Ethernet,
etc), and how to achieve and implement reliability, multicast, etc), and how to achieve and implement reliability, multicast,
ordering, etc. The ForCES TML is specifically addressed in a ordering, etc. The ForCES TML is specifically addressed in a
separate ForCES TML Specification document. separate ForCES TML Specification document.
3. Overview 3. Overview
The reader is referred to the Framework document [RFC3746], and in The reader is referred to the Framework document [RFC3746], and in
particular sections 3 and 4, for architectural overview and where and particular sections 3 and 4, for an architectural overview and an
how the ForCES protocol fits in. There may be some content overlap explanation of how the ForCES protocol fits in. There may be some
between the framework document and this section in order to provide content overlap between the framework document and this section in
clarity. order to provide clarity.
3.1 Protocol Framework 3.1 Protocol Framework
Figure 1 below is reproduced from the Framework document for clarity. Figure 1 below is reproduced from the Framework document for clarity.
It shows a NE with two CEs and two FEs. It shows a NE with two CEs and two FEs.
--------------------------------------- ---------------------------------------
| ForCES Network Element | | ForCES Network Element |
-------------- Fc | -------------- -------------- | -------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | | | CE Manager |---------+-| CE 1 |------| CE 2 | |
skipping to change at page 10, line 35 skipping to change at page 9, line 35
------------------------------------------------- -------------------------------------------------
| ForCES Interface | | ForCES Interface |
------------------------------------------------- -------------------------------------------------
| | | | | | | | | | | | | |
|LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . |
| | | | |fier | | | | | | |fier | |
------------------------------------------------- -------------------------------------------------
Figure 2: Examples of CE and FE functions Figure 2: Examples of CE and FE functions
The ForCES Interface shown in Figure B constitutes two pieces: the PL The ForCES Interface shown in Figure 2 constitutes two pieces: the PL
and TML layer. and TML layer.
This is depicted in Figure 3 below. This is depicted in Figure 3 below.
+------------------------------------------------ +------------------------------------------------
| CE PL layer | | CE PL layer |
+------------------------------------------------ +------------------------------------------------
| CE TML layer | | CE TML layer |
+------------------------------------------------ +------------------------------------------------
^ ^
skipping to change at page 11, line 40 skipping to change at page 10, line 40
Figure 3: ForCES Interface Figure 3: ForCES Interface
The PL layer is in fact the ForCES protocol. Its semantics and The PL layer is in fact the ForCES protocol. Its semantics and
message layout are defined in this document. The TML Layer is message layout are defined in this document. The TML Layer is
necessary to connect two ForCES PL layers as shown in Figure 3 above. necessary to connect two ForCES PL layers as shown in Figure 3 above.
The TML is out of scope for this document but is within scope of The TML is out of scope for this document but is within scope of
ForCES. This document defines requirements the PL needs the TML to ForCES. This document defines requirements the PL needs the TML to
meet. meet.
Both the PL and TML layers are standardized by the IETF. While only Both the PL and the TML layers are standardized by the IETF. While
one PL layer is defined, different TMLs are expected to be only one PL layer is defined, different TMLs are expected to be
standardized. To interoperate the TML layer at the CE and FE are standardized. To interoperate the TML layer at the CE and FE are
expected to be of the same definition. expected to conform to the same definition.
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).
3.1.1 The PL layer 3.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 throw tearing down such associations. An FE uses the PL layer to throw
various subscribed-to events to the CE PL layer as well as respond to various subscribed-to events to the CE PL layer as well as respond to
various status requests issued from the CE PL. The CE configures various status requests issued from the CE PL. The CE configures
both the FE and associated LFBs attributes using the PL layer. In both the FE and associated LFBs attributes using the PL layer. In
addition the CE may send various requests to the FE to activate or addition the CE may send various requests to the FE to activate or
deactivate it, reconfigure its HA parametrization, subscribe to deactivate it, reconfigure its HA parametrization, subscribe to
specific events etc. More details in section Section 6. specific events etc. More details in Section 6.
3.1.2 The TML layer 3.1.2 The TML layer
The TML layer is essentially responsible for transport of the PL The TML layer is essentially responsible for transport of the PL
layer messages. The TML is where the issues of how to achieve layer messages. The TML is where the issues of how to achieve
transport level reliability, congestion control, multicast, ordering, transport level reliability, congestion control, multicast, ordering,
etc are handled. It is expected more than one TML will be etc are handled. It is expected more than one TML will be
standardized. The different TMLs each could implement things standardized. The different TMLs each could implement things
differently based on capabilities of underlying media and transport. differently based on capabilities of underlying media and transport.
However, since each TML is standardized, interoperability is However, since each TML is standardized, interoperability is
skipping to change at page 13, line 7 skipping to change at page 12, line 7
b. the ID for the FE or CE would also be issued at this point. b. the ID for the FE or CE would also be issued at this point.
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 "send up to 3 association messages each 1 second apart" Vs "
send up to 4 association messages with increasing exponential send up to 4 association messages with increasing exponential
timeout". timeout".
3.2 ForCES Protocol Phases 3.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. operates.
3.2.1 Pre-association 3.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 some In a simple setup, the configuration is static and is read from a
saved config file. All the parameters for the association phase are saved config file. All the parameters for the association phase are
well known after the pre association phase is complete. A protocol well known after the pre-association phase is complete. A protocol
such as DHCP may be used to retrieve the config parameters instead of such as DHCP may be used to retrieve the config parameters instead of
reading from a static config file. Note this will still be reading them from a static config file. Note, this will still be
considered static pre-association. Dynamic configuration may also considered static pre-association. Dynamic configuration may also
happen in the Fc, Ff and Fl reference points. Vendors may use their happen using the Fc, Ff and Fl reference points. Vendors may use
own proprietary service discovery protocol to pass the parameters. their own proprietary service discovery protocol to pass the
parameters.
We reproduce some scenarios from the Framework Document to show a the following are scenarios reproduced from the Framework Document
pre-association example. to show a pre-association example.
<----Ff ref pt---> <--Fc ref pt-------> <----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) (security exchange) (security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication 1|<------------>| authentication 1|<----------->|authentication
| | | | | | | |
(FE ID, attributes) (CE ID, attributes) (FE ID, attributes) (CE ID, attributes)
2|<-------------| request 2|<------------|request 2|<-------------| request 2|<------------|request
skipping to change at page 14, line 26 skipping to change at page 13, line 26
3|------------------------------->| | 3|------------------------------->| |
| | | | | | | |
| | | | | | | |
Figure 5: An example of a message exchange over the Fl reference Figure 5: An example of a message exchange over the Fl reference
point point
Before the transition to the association phase, the FEM will have Before the transition to the association phase, the FEM will have
established contact with the appropriate CEM component. established contact with the appropriate CEM component.
Initialization of the ForCES interface will be completed, and Initialization of the ForCES interface will be completed, and
Authentication and capabilities discovery may be complete as well. authentication as well as capability discovery may be complete as
Both the FE and CE would know how to connect to each other for well. Both the FE and CE would have the necessary information for
configuration, accounting, identification and authentication connecting to each other for configuration, accounting,
purposes. Both sides are also knowledgeable of all necessary identification and authentication purposes. Both sides also would
protocol parameters such as timers, etc. The Fl reference point may have all the necessary protocol parameters such as timers, etc. The
continue to operate during the association phase and may be used to Fl reference point may continue to operate during the association
force a disassociation of an FE or CE. Because the Pre-association phase and may be used to force a disassociation of an FE or CE.
phase is out of scope, we do not discuss these details any further. Because the pre-association phase is out of scope, these details are
The reader is referred to the framework document for more detailed not discussed any further in this specification. The reader is
referred to the framework document [RFC3746] for more detailed
discussion. discussion.
3.2.2 Post-association 3.2.2 Post-association
In this phase, the FE and CE components talk to each other using the In this phase, the FE and CE components communicate with each other
ForCES protocol (PL over TML) as defined in this document. There are using the ForCES protocol (PL over TML) as defined in this document.
three sub-phases: Association setup state, Established State, and There are three sub-phases:
Association teardown state. o Association setup state
o Established State
o Association teardown state.
3.2.2.1 Association setup state 3.2.2.1 Association setup state
The FE attempts to join the NE. The FE may be rejected or accepted. The FE attempts to join the NE. The FE may be rejected or accepted.
Once granted access into the NE, capabilities exchange happen with Once granted access into the NE, capabilities exchange happens with
the CE querying the FE. Armed with the FE capability knowledge, the the CE querying the FE. Once the CE has the FE capability
CE can offer an initial configure (possibly to restore state) and information, the CE can offer an initial configure (possibly to
query certain attributes within either an LFB or the FE itself. restore state) and can query certain attributes within either an LFB
or the FE itself.
A lot more details are provided in the protocol scenarios section. More details are provided in the protocol scenarios section.
On successful completion of this state, the FE joins the NE and is On successful completion of this state, the FE joins the NE and is
moved to the Established State. moved to the Established State.
3.2.2.2 Association Established state 3.2.2.2 Association Established state
In this state the FE is continuously updated or queried. The FE may In this state the FE is continuously updated or queried. The FE may
also send asynchronous event notifications to the CE or synchronous also send asynchronous event notifications to the CE or synchronous
heartbeat notifications. This continues until a termination is heartbeat notifications. This continues until a termination is
initiated by either the CE or FE. initiated by either the CE or the FE.
Refer to section on protocol scenarios for more details. Refer to section on protocol scenarios Section 7 for more details.
3.3 Protocol Mechanisms 3.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.
3.3.1 Of Transactions, Atomicity and 2 Phase Commits 3.3.1 Of Transactions, Atomicity and 2 Phase Commits
A transaction is a sequence of operations that is guaranteed to be A transaction is a sequence of operations that is guaranteed to be
atomic in the presence of any failures by the CEs or FEs. Operation atomic in the presence of any failures by the CEs or FEs. Operation
in this sense implies the PL operation within the message body TLV. in this sense implies the PL operation within the message body TLV.
An example of a transaction could be a config PL msg with a sequence An example of a transaction could be a config PL msg with a sequence
of operations: "route-add A B,C:route-del X" (each operation in its of operations: "route-add A B,C:route-del X" (each operation in its
own TLV). own TLV).
If a transaction is split across more than one message, then all If a transaction is split across more than one message, then all
message batch must arrive at the destination before they are executed messages in the the transaction MUST arrive at the destination before
on either the LFB or FE. All operations are executed serially in the they are executed on either the LFB or FE. All operations are
order specified by the transaction. If any of the sequence of executed serially in the order specified by the transaction. If any
operations in a transaction fails then the transaction is declared as of the sequence of operations in a transaction fails then the
a failure. This is an all-or-nothing approach and is needed to transaction is declared as a failure. This is an all-or-nothing
ensure consistency of a transaction across multiple FEs. approach and is needed to ensure consistency of a transaction across
multiple FEs.
A transaction may be atomic within an FE alone or across the NE. In A transaction may be atomic within an FE alone or across the NE. In
both cases the atomic requirement for a transaction MUST be met. The both cases the atomic requirement for a transaction MUST be met. The
PL message header exposes ability to mark a start of transaction and PL message header exposes the ability to mark a start of transaction
end of transaction using flags. These flags can be used to derive a and end of transaction using flags. These flags can be used to
classical transactional two phase commit[ACID paper ref here]. derive a classical transactional two phase commit[ACID paper ref
here].
3.3.2 FE Protocol Object 3.3.2 FE, CE, and FE protocol LFBs
The FE Protocol Object is a logical entity in each FE that is used to Whereas the four key PL messages, Association Setup, Response, and
control the ForCES protocol. It is defined in the same fashion as Teardown, as well as Heartbeat, have a specific types assigned mostly
LFBs. The FE Protocol Object can be manipulated using the standard for simplicity and monitoring reasons, all other PL messages follow
Config/Query messages. The FE Protocol Object Type ID is assigned the LFB structure as this provides more flexibility for future
the value 0x1. The FE Protocol Instance ID is assigned the value enhancements. In addition, this shows how the ForCES protocol itself
0x1. There must always be one and only one instance of the FE can be controlled by the very same type of structures (LFBs) it uses
Protocol Object in an FE. The values of the attributes in the FE to control functions such as IP forwarding, filtering, etc.
Protocol Object have pre-defined default values that are specified
here. Unless explicit changes are made to these values using Config
messages from the CE, these default values MUST be used for the
operation of the protocol.
The FE Protocol Object consists of the following elements: To achieve this, the following LFBs are used:
FE Protocol events that can be subscribed/unsubscribed: o FE Protocol LFB
FE heartbeat o FE LFB
FE TML events (TBD) o CE LFB
FE Protocol capabilities: These LFBs are detailed in Section 6.1. A short description is
Supported ForCES protocol version(s) by the FE provided here:
Supported ForCES FE model(s) by the FE o The FE Protocol LFB is a logical entity in each FE that is used to
Some TML capability description(s) control the ForCES protocol. The CE operates on this LFB to
FE Protocol attributes: subscribe or unsubscribe to Heartbeat messages, define the
current version of the ForCES protocol Heartbeat interval, or to discover which ForCES protocol version
current version of the FE model is supported and which TMLs the FE supports. The FE Protocol LFB
Association Expiry Timer also contains the various ForCES ID to be used: unicast IDs and
Heartbeat Interval table of the PL multicast IDs the FE must be listening to. [TBD:
Primary CE do we need a CE Protocol LFB?]
FE failover and restart policy o The FE LFB (referred to as "FE attributes" in the model draft)
should not be confused with the FE Protocol Object. The FE LFB is
a logical entity in each FE and contains attributes relative to
the FE itself, and not to the operation of the ForCES protocol
between the CE and the FE. Such attributes can be FEState (refer
to model draft), vendor, etc. The FE LFB contains in particular
an table that maps a virtual LFB Instance ID to one or more
Instance IDs of LFBs in the FE.
o The CE LFB is the counterpart of the FE LFB. The CE LFB is a
logical entity in each CE and contains attributes relative to the
CE itself, and not to the operation of the ForCES protocol between
the CE and the FE. This LFB can be used to convey event
notifications from a CE to FEs. Some events may be sent by the CE
without prior subscription by the FEs.
The FE Object (referred to as "FE attributes" in the model draft) 3.3.3 Scaling by Concurrency
should not be confused with the FE Protocol Object. The FE Object
contains attributes relative to the FE itself, and not to the
operation of the ForCES protocol between the CE and the FE. Such
attributes can be FEState (refer to model draft), vendor, etc. The
FE Object Type ID is assigned the value 0x2. The FE Protocol
Instance ID is assigned the value 0x1. There must always be one and
only one instance of the FE Object in an FE.
The FE Object consists of the following elements It is desirable that the PL layer not become the bottleneck when
FE Events: larger bandwidth pipes become available. To pick a mythical example
FEStatusChange (FE Up/Down/Active/Inactive/Failover) in today's terms, if a 100Gbps pipe is available and there is
FE DoS alert sufficient work then the PL layer should be able to take advantage of
FE capability change this and use all of the 100Gbps pipe. Two mechanisms are provided to
FE attributes: achieve this. The first one is batching and the second one is a
FE Behavior Exp. Timer command window.
HA Mode
3.3.3 Scaling by Concurrency Batching is the ability to send multiple commands (such as config) in
one PDU. The size of the batch will be affected by, amongst other
things, the path MTU. The commands may be part of the same
transaction or part of unrelated transactions that are independent of
each other.
It is desirable that the PL layer is not the bottleneck when larger Command windowing allows for pipelining of independent transactions
bandwidth pipes become available. To pick a mythical example in which do not affect each other. Each independent transaction could
todays terms, if a 100Gbps pipe was made available and there is consist of one or more batches.
sufficient work then the PL layer should take advantage and use all
of the 100Gbps pipe. Two semantics are allowed to achieve this. The
first one is batching and the second one is a command window.
Batching is ability to send multiple commands (such as config) in one
PDU. The size of the batch will be affected by amongst other things
the path MTU. The commands may be part of the same transaction or
unrelated transactions which are independent of each other. Command
windowing allows for pipelining of independent transactions which do
not affect each other. Each independent transaction could be one or
more batches.
3.3.3.1 Batching 3.3.3.1 Batching
TBD There are several batching levels at different protocol hierarchies.
o multiple PL PDUs can be aggregated under one TML message
o multiple LFB classes and instances can be addressed within one PL
PDU
o Multiple operations can be addressed to a single LFB class and
instance
3.3.3.2 Command Pipelining 3.3.3.2 Command Pipelining
TBD TBD
4. TML Requirements 4. 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 example they could be defined to be delivered via hardware or
inter-TML protocol level schemes. inter-TML protocol level schemes.
Each TML must describe how it contributes to achieving the listed Each TML must describe how it contributes to achieving the listed
ForCES requirements. If for any reason a TML does not provide a ForCES requirements. If for any reason a TML does not provide a
service listed below a justification needs to be provided. service listed below a justification needs to be provided.
1. Reliability 1. Reliability
As defined by RFC 3654, section 6 #6. As defined by RFC 3654, section 6 #6.
2. Security 2. Security
TML provides security services to the ForCES PL. TML layer TML provides security services to the ForCES PL. TML layer
should support following security services and describe how they should support the following security services and describe how
are achieved. they are achieved.
* Endpoint authentication of FE and CE. * Endpoint authentication of FE and CE.
* Message Authentication * Message Authentication
* Confidentiality service * Confidentiality service
3. Congestion Control 3. Congestion Control
The congestion control scheme used needs to be defined. The congestion control scheme used needs to be defined.
Additionally, under what circumstances is notification sent to Additionally, the circumstances under which notification is sent
the PL to notify it of congestion. to the PL to notify it of congestion must be defined.
4. Uni/multi/broadcast addressing/delivery if any 4. Uni/multi/broadcast addressing/delivery if any
If theres any mapping between PL and TML level Uni/Multi/ If there is any mapping between PL and TML level
Broadcast addressing it needs to be defined. Uni/Multi/Broadcast addressing it needs to be defined.
5. Timeliness 5. Timeliness
Editorial Note: Does the TML allow for obsoleting msgs? If yes, Editorial Note: Does the TML allow for obsoleting msgs? If yes,
it needs to say how. it needs to define how.
6. HA decisions 6. HA decisions
It is expected that availability of transport links is the TMLs It is expected that availability of transport links is the TML's
responsibility. However, on config basis, the PL layer may wish responsibility. However, on config basis, the PL layer may wish
to participate in link failover schemes and therefore the TML to participate in link failover schemes and therefore the TML
must provide this capability. must support this capability.
Please refer to the HA Section Section 8 for details. Please refer to the HA Section Section 8 for details.
7. Encapsulations used. 7. 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.
8. Prioritization 8. 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. TML needs to define how this is achieved.
4.1 TML Parameterization 4.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 parameters may include: Some of the configured parameters may include:
o PL ID o PL ID
o Connection Type and associated data. For example if a TML uses o Connection Type and associated data. For example if a TML uses
IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses
need to be configured. need to be configured.
o number of transport connections o Number of transport connections
o Connection Capability, such as bandwidth, etc. o Connection Capability, such as bandwidth, etc.
o Allowed/Supported Connection QoS policy (or Congestion Control o Allowed/Supported Connection QoS policy (or Congestion Control
Policy) Policy)
5. Common Header 5. Common Header
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length | |version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID | | Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Common Header Figure 6: Common Header
The message is 32 bit aligned. The message is 32 bit aligned.
Version (4 bit): Version (4 bit):
Version with a 2 bit major and 2 bit minor. 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. field.
Command (8 bits): Command (8 bits):
Commands are defined in Section 6. Commands are defined in Section 6.
Source ID (32 bit): Source ID (32 bit):
Dest ID (32 bit): Dest ID (32 bit):
* Above are 32 bit IDs which recognize the termination point. * Each of the source and Dest IDs are 32 bit IDs which
Ideas discussed so far are desire to recognize if ID belongs recognize the termination points. Ideas discussed so far are
to FE or CE by inspection. Suggestions for achieving this desire to recognize if ID belongs to FE or CE by inspection.
involves partitioning of the ID allocation. Another Suggestions for achieving this involves partitioning of the
alternative maybe to use flags to indicate direction (this ID allocation. Another alternative maybe to use flags to
avoids partition). indicate direction (this avoids partition).
* IDs will allow multi/broad/unicast * IDs will allow multi/broad/unicast
* Addressing * Addressing
a. As ForCES may run between multiple CEs and FEs and over a. As ForCES may run between multiple CEs and FEs and over
different protocols such as IPv4 and IPv6, or directly different protocols such as IPv4 and IPv6, or directly
over Ethernet or other switching-fabric interconnects, it over Ethernet or other switching-fabric interconnects, it
is necessary to create an addressing scheme for ForCES is necessary to create an addressing scheme for ForCES
entities. Mappings to the underlying TML-level entities. Mappings to the underlying TML-level
addressing can then be defined as appropriate. addressing can then be defined as appropriate.
b. Fundamentally, unique IDs are assigned to CEs and FEs. A b. Fundamentally, unique IDs are assigned to CEs and FEs. A
split address space is used to distinguish FEs from CEs. split address space is used to distinguish FEs from CEs.
skipping to change at page 22, line 18 skipping to change at page 21, line 19
only be applied to LFBs belonging to that VPN ID. only be applied to LFBs belonging to that VPN ID.
Sequence (32 bits) Sequence (32 bits)
Unique to a PDU. [Discussion: There may be impact on the effect Unique to a PDU. [Discussion: There may be impact on the effect
of subsequence numbers]. of subsequence numbers].
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).
Flags(32 bits): Flags(32 bits):
Identified so far: Identified so far:
* ACK indicator(2 bit) - ACK indicator(2 bit)
The description for using the two bits is: The description for using the two bits is:
'NoACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 'NoACK' (00)
'SuccessACK'(01)
'UnsuccessACK'(10)
'ACKAll' (11) 'ACKAll' (11)
* - Priority (3 bits)
unknown/undecided. TBD
* Throttle flag? - Throttle flag
* batch (2 bits) - Batch (2 bits)
* Atomicity (1 or 2 bits) - Atomicity (1 or 2 bits)
Editorial Note: There are several open issues, listed below, in the Editorial Note: There are several open issues, listed below, in the
header which still need to be settled: header which still need to be settled:
1. Parallelization of PL Windowing/subsequence 1. Parallelization of PL Windowing/subsequence
Someone to look into ISCSI Someone to look into ISCSI
2. events and replies and relation to peer to peer 2. events and replies and relation to peer to peer
vs master slave vs master slave
3. We need to discuss whether some of the Flags 3. We need to discuss whether some of the Flags
such as those for Atomicity, Batching are needed such as those for Atomicity, Batching are needed
in the common header or only belong to the in the common header or only belong to the
Config message. Config message.
6. Protocol Messages 6. Protocol Messages
6.1 Association Messages The general structure of most messages is as follows (in BNF format):
PL level PDU := MAINHDR<LFBselect>+
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER := <OPERATION [<path-data>]*>+
o MAINHDR defines msg type, Target FE/CE ID etc. The MAINHDR also
defines the content. As an example the content of a "config"
message would be different from an "association" message.
o LFBCLASSID is a 32 bit unique identifier per LFB class defined at
class creation time.
o LFBInstance is a 32 bit unique instance identifier of an LFB class
o OPERATION is one of {ADD,DEL,etc.} depending on the message type
o path-data identifies the exact element targeted. It may have zero
or more data values associated.
In summary this approach has the following characteristic:
o there can be one or more LFB Class + InstanceId combo targeted in
a message (batch)
o There can one or more operation on an addressed LFB
classid+instanceid combo(batch)
o There can be one or more path targets per operation (batch)
o Paths may have zero or more data values associated (flexibility
and operation specific)
It should be noted that the above is optimized for the case of a a
single classid+instance targeting. To target multiple instances
within the same class, multiple LFBselect are needed.
6.1 Core ForCES LFBs
There are three LFBs that are used to control the operation of the
ForCES protocol and to interact with FEs and CEs:
FE protocol LFB
FE LFB
CE LFB
Although these LFBs have the same form and interface as other LFBs,
they are special in many respects: they have fixed well-known LFB
Class and Instance IDs. They are statically defined (no dynamic
instantiation allowed) and their status cannot be changed by the
protocol: any operation to change the state of such LFBs (for
instance, in order to disable the LFB) must result in an error.
Moreover, these LFBs must exist before the first ForCES message can
be sent or received. All attributes in these LFBs must have
pre-defined default values. Finally, these LFBs do not have input or
output ports and do not integrate into the intra-FE LFB topology.
6.1.1 FE Protocol LFB
The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB Class ID is
assigned the value 0x1. The FE LFB Instance ID is assigned the value
0x1. There must always be one and only one instance of 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.
Unless explicit changes are made to these values using Config
messages from the CE, these default values MUST be used for the
operation of the protocol.
The FE Protocol LFB consists of the following elements:
o FE Protocol events that can be subscribed/unsubscribed:
* FE heartbeat
* FE TML events (TBD)
o FE Protocol capabilities (read-only):
* Supported ForCES protocol version(s) by the FE
* Supported ForCES FE model(s) by the FE
* Some TML capability description(s)
o FE Protocol attributes (can be read and set):
* Current version of the ForCES protocol
* Current version of the FE model
* FE unicast ID
* FE multicast ID(s) (list)
* Association Expiry Timer
* Heartbeat Interval
* Primary CE
* FE failover and restart policy
* CE failover and restart policy
Note: Is there a difference between the CE and FE failover
policies?
TBD: Define default values for each attribute where
applicable.
6.1.2 FE LFB
The FE LFB is a logical entity in each FE and contains attributes
relative to the FE itself, and not to the operation of the ForCES
protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB
Instance ID is assigned the value 0x1. There must always be one and
only one instance of the FE LFB in an FE.
The FE LFB consists of the following elements:
FE Events:
* FEAllEvents: subscribing to this corresponds to subscribing to
all events below
* FEStatusChange: events that signal FE Status:
+ Up
+ Down
+ Active
+ Inactive
+ Failover
* FE DoS alert
* FE capability change
FE attributes:
* FEStatus: to set the FE mode as:
+ Active
+ Inactive
+ Shutdown
Note: This replaces the State Maintenance messages
* FELFBInstancelist
* FENeighborList
* MIID table: a list of virtual LFB Instance IDs that map to a
list of Instance IDs of LFBs in that FE
* FE Behavior Exp. Timer
* HA Mode
* FE DoS protection policy
* FEPrivateData: Proprietary info such as name, vendor, model.
Note: The attributes below were previously under Query
message.
* Inter-FE topology Intra-FE topology
6.1.3 CE LFB
The CE LFB is a logical entity in each CE and contains attributes
relative to the CE itself, and not to the operation of the ForCES
protocol.
The CE LFB consists of the following elements:
CE Events:
* CEAllEvents: subscribing to this corresponds to subscribing to
all events listed below.
Note: Do we want to allow an FE to explicitly subscribe to CE
events?
* CEStatusChange: events that signal CE
Up/Down/Active/Inactive/Failover.
Note: Such events do not necessarily need to be subscribed to,
they can fire even without subscription and be sent to
the FE
Note: TBD: what else do we need in the CE LFB?
6.2 Association Messages
The ForCES Association messages are used to establish and teardown The ForCES Association messages are used to establish and teardown
associations between FEs and CEs. associations between FEs and CEs.
6.1.1 Association Setup Message 6.2.1 Association Setup Message
This message is sent by the FE to the CE to setup a ForCES This message is sent by the FE to the CE to setup a ForCES
association between them. This message could also be used by CEs to association between them. This message could also be used by CEs to
join a ForCES NE, however CE-to-CE communication is not covered by join a ForCES NE, however CE-to-CE communication is not covered by
this protocol. this protocol.
Message transfer direction: Message transfer direction:
FE to CE FE to CE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Association The Message Type in the header is set MessageType= 'Association
Setup'. The ACK flag in the header is ignored, because the setup Setup'. The ACK flag in the header is ignored, because the setup
message will always expect to get a response from the message message will always expect to get a response from the message
receiver (CE) whether the setup is successful or not. The Src ID receiver (CE) whether the setup is successful or not. The Src ID
(FE ID) may be set to O in the header which means that the FE (FE ID) may be set to O in the header which means that the FE
would like the CE to assign a FE ID for the FE in the setup would like the CE to assign a FE ID for the FE in the setup
response message. response message.
Message body: Message body:
The setup message body consists of one optional TLV, the format of The setup message body consists of LFBSelect & FE Name TLV, the
which is as follows: format of which is as follows:
main hdr (eg type = Association setup)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = Operation = SHOW
|
+-- FE NAME
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 = HBI | Length | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Interval | | LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FE Name string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ FE Object LFB (including HBI, etc) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Figure 9
Type (16 bits): Type (16 bits):
Currently only one Type defined, HBI-heart beat interval. LFB Select
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in bytes. Length of the TLV including the T and L fields, in bytes.
Heartbeat Interval (32 bits): FE Object LFB:
This indicates the current HB interval on the FE in milliseconds. This contains the FE parameters e.g. HBI will be exchanged with
A default value for this will be defined. the CE using this LFB.
FE Name String:
This is a string which contains the FE name (part of FE Object
LFB).
Editorial Note: Whether HBI belongs to the setup is still under
discussion.
Editorial Note: In certain situations (such as use of multicast Editorial Note: In certain situations (such as use of multicast
IDs), it might not be possible to make use of the IDs), it might not be possible to make use of the
procedure described above for the FE to procedure described above for the FE to
dynamically obtain an ID from the CE. Such dynamically obtain an ID from the CE. Such
situations need to be identified. situations need to be identified.
6.1.2 Association Setup Response Message 6.2.2 Association Setup Response Message
This message is sent by the CE to the FE in response to the Setup This message is sent by the CE to the FE in response to the Setup
message. It indicates to the FE whether the setup is successful or message. It indicates to the FE whether the setup is successful or
not, i.e. whether an association is established. not, i.e. whether an association is established.
Message transfer direction: Message transfer direction:
CE to FE CE to FE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Setup The Message Type in the header is set MessageType= 'Setup
Response'. The ACK flag in the header is always ignored, because Response'. The ACK flag in the header is always ignored, because
the setup response message will never expect to get any more the setup response message will never expect to get any more
response from the message receiver (FE). The Dst ID in the response from the message receiver (FE). The Dst ID in the
header will be set to some FE ID value assigned by the CE if the header will be set to some FE ID value assigned by the CE if the
FE had requested that in the setup message (by SrcID = 0). FE had requested that in the setup message (by SrcID = 0).
Message body: Message body:
The setup response message body consists of one TLV, the format The setup response message body consists of LFBSelect & Result
of which is as follows: TLV, the format of which is as follows:
main hdr (eg type = Association setup response)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = FEResult
|
+-- resultvalue
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 = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ FE Object LFB (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Result | Length | | Type = Result | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | Reserved | | Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Figure 10
Type (16 bits): Type (16 bits):
Currently only one Type i.e. Setup Result is required. Other LFB Select
TLVs are optional.
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in bytes. Length of the TLV including the T and L fields, in bytes.
FE Object LFB:
The FE parameters e.g. HBI may be exchanged using this LFB.
Result (16 bits): Result (16 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 FE request was rejected by the CE.
6.1.3 Association Teardown Message 6.2.3 Association Teardown Message
This message can be sent by the FE or CE to any ForCES element to end This message can be sent by the FE or CE to any ForCES element to end
its ForCES association with that element. its ForCES association with that element.
Message transfer direction: Message transfer direction:
CE to FE, or FE to CE (or CE to CE) CE to FE, or FE to CE (or CE to CE)
Message Header: Message Header:
The Message Type in the header is set MessageType= "Asso. The Message Type in the header is set MessageType= "Asso.
Teardown"(TBD?). The ACK flag in the header is always ignored, Teardown". The ACK flag in the header is always ignored, because
because the teardown message will never expect to get any the teardown message will never expect to get any response from
response from the message receiver. the message receiver.
Message body: Message body:
The association teardown message body consists of one TLV, the The association teardown message body consists of LFBSelect &
format of which is as follows: FEReason TLV, the format of which is as follows:
main hdr (eg type = Association tear)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
|
+--- T = FEReason
|
+-- "myreason"
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 = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = T.reason | Length | | Type = T.reason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason (optional) | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
Figure 10
Type (16 bits): Type (16 bits):
Currently only one Type defined - Teardown Reason. LFB Select
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in bytes. Length of the TLV including the T and L fields, in bytes.
T.reason (32 bits): T.reason (32 bits):
This indicates the reason why the association is being This indicates the reason why the association is being
terminated. terminated.
6.2 Query and Response Messages 6.3 Configuration Messages
Editorial Note: If the approach of using an FE Protocol & FE Object
is fully adopted and no other reason for having FE
TLVs is identified, then no distinction will be
further made in the TLV types between FE* and LFB*.
As a result, the Type ID and Instance ID in the TLV
will also be used to identify the FE Protocol
Object, with specific values as mentioned in Section
3.3.2
The ForCES query and response messages are used for one ForCES
element (CE or FE) to query other ForCES element(s) for various kinds
of information. Current version of ForCES protocol limits the use of
the messages only for CE to query information of FE. The information
to be queried in FE can be categorized into two types:
1) FE (coarse layer) information
This type of information is about the property of an FE, taking the
FE as a whole, e.g., the total available memory space in the FE. To
query this type of information, we should take the whole FE as the
addressing destination. Information of this type includes:
o Inter-FE topology
o Intra-FE topology, that is, LFB topology
o FE capabilities
o FE attributes
o FE statistics
Another way to recognize FE coarse layer property is to define two
objects, the 'FE Protocol Object' and the 'FE Object' at this coarse
layer. See Section 3.3.2 for more details.
2) LFB information
This type of information is about property of an LFB inside an FE,
e.g., routing rules of a Forwarder LFB in an FE. To query this type
of information, we should take the LFB as the addressing destination.
Information of this type include:
o LFB capabilities The ForCES Configuration messages are used by the CEs to configure
o LFB attributes the FEs in a ForCES NE and report the results back to the CE.
o LFB statistics
6.2.1 Query Message 6.3.1 Config Message
As usual, a query message is composed of a common header and a This message is sent by the CE to the FE to configure FE or LFB
message body that consists of one or more TLV data format. Detailed attributes. This message is also used by the CE to
description of the message is as below. subscribe/unsubscribe to FE and LFB events.
Message transfer direction: Message transfer direction:
Current version limits the query message transfer direction only CE to FE
from CE to FE.
Message Header: Message Header:
The Message Type in the header is set to MessageType= 'Query'. The Message Type in the header is set MessageType= 'Config'. The
The ACK flag in the header SHOULD be set 'ACKAll', meaning a full ACK flag in the header is can be used by the CE to turn off any
response for a query message is always expected. If the ACK flag response from the FE. The default behavior is to turn on the ACK
is set other values, the meaning of the flag will then be to get the config response from the FE.
ignored, and a full response will still be returned by message
receiver.
Message body: Message body:
The query message body consists of (at least) one or more than The Config message body consists of one or more TLVs, the format
one TLVs that describe entries to be queried. According to the of a single (LFB) TLV is as follows:
queried information being FE (coarse layer) information or LFB
information as described above, the message body TLV has
different data format as below:
To query FE (coarse layer) information, the message body TLV data
format is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type='FEQuery' | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Query Entry #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Query Entry #2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Query Entry #N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To query LFB information, the message body TLV data format is: main hdr (eg type = config)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = target LFB class
| |
| |
| +-- LFBInstance = target LFB instance
| |
| |
| +-- T = operation { ADD, DEL, etc}
| | |
| | +-- // one or more path targets
| | // under discussion
| |
| +-- T = operation { ADD, DEL, etc}
| | |
| | +-- // one or more path targets
| | // under discussion
| |
| +-- T = operation { ADD, DEL, etc}
| | |
| | +-- // one or more path targets
| | // under discussion
| |
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='LFBQuery' | Length | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ID | Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Query Entry #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Query Entry #2 ~ | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Query Entry #N ~ | Type = Operations (ADD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Figure 11 ~ Config data ~
| |
Editorial Note:
1. Under discussion is, when an 'FE Protocol
Object' idea is adopted, above two kind of
data formats may be mapped into one format,
with the Type ID and Instance ID changed to
Managed Object (MO) Type ID and MO Instance
ID, and with two specific MO Type ID and
Instance ID for 'FE Protocol Object' and 'FE
Object', and others for 'FE LFB Object'.
2. Under discussion is, do we need to support
multiple objects addressing at the LFB Type
and LFB Instance layer? One simple way to
support multiple LFB types or instances is
to use TLVs to identify the group of Type
IDs and Instance IDs, rather than only one
Type and Instance ID. A range of Instance
IDs may also be supported in this way.
Query Entry:
This is a TLV that describes the entry to be queried, as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type = Operations (DEL) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Description of the Query Entry ~ | |
~ Config data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 Figure 12
Type: Type (16 bits):
[Under discussion and TBD] LFB Select.
Length (16 bits):
Editorial Note: There is a debate on how the Type here can be Length of the TLV including the T and L fields, in bytes.
used. One possible use for the Type is to LFB Class ID (16 bits):
specify the encoding type for the TLV value. This field uniquely recognizes the LFB class/type.
The possible encoding types are that like XML, LFB Instance ID (16 bits):
binary ID based TLV coding, etc, therefore, the This field uniquely identifies the LFB instance.
possible value for the Type may be Type (16 bits):
'XMLEncoding', 'ID-BasedBinaryEncoding', etc. The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT
The Cons say that it may be impractical to SUBSCRIBE, EVENT UNSUBSCRIBE, PACKET SUBSCRIBE, PACKET
directly use XML encoding in the protocol UNSUBSCRIBE, CANCEL.
format, leaving no encoding type other than
ID-based binary encoding to be specified, hence
no need to specify encoding type. Another
possible use of the Type is to number the
entries, by which a more flexible response based
on the number may become be achieved.
Description of the Query Entry:
This field presents the detailed description about the entry to
be queried. The encoding of the description is based on the
ForCES FE model if the entry is defined by FE model, or based on
vendor specifications if the entry is defined by vendors. Note
that the encoding is responsible for the 32 bits alignment of the
description field. Usually, the description should include
information about the name (or the name ID) of the entry to be
queried. Occasionally, it may also include some more
information, like some conditions that the queried entry is
required to meet. For instance, consider a case in which a CE is
going to query a Forwarder LFB in an FE for its current routing
table information. In this case, CE may be interested in knowing
(querying) all routing rules in the table, CE may also be
interested in only knowing (querying) a few routing rules that
meet some specific conditions, e.g., routing rules whose source
IP address should match '210.33.X.X'. In the former case, only
the name of the LFB attribute (as 'routing table') should be told
in the query entry description, while in the latter case, the
matching conditions should also be told in the description.
Taking another policer LFB as one more example, the policer LFB
may have attribute like the provisions (rules) for the policer,
therefore, in the query entry TLV, we may set the queied entry
name as the 'Provision'. To only set the name of the attribute
as 'Provision' will dump all provision items in the LFB; while to
set the attribute name and followed by some conditions will dump
the provision items that meet the conditions. The index of the
provision items can also be as the conditions, e.g., to set the
conditions as 'the index of the provision items should range from
11 to 15', then will return query result that only include the
provision items ranging from 11 to 15.
6.2.2 Query Response Message Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Config Data (variable length):
This will carry LFB specific data (<path>, single or Array LFB
specific entries). The config data might itself be of the form
of a TLV.
*Note: FE Activate/Deactivate, Shutdown FE commands for State
Maintenance will be sent using Config messages.
*Note: For Event subscription, the events will be defines by the
individual LFBs.
When receiving a query message, the receiver should process the 6.3.2 Config Response Message
message and come up with a query result. The receiver sends the
query result by use of the Query Response Message back to the query
message sender. The query result can be the information being
queried if the query operation is successful, or can also be error
codes if the query operation fails, indicating the reasons for the
failure.
A query response message is also composed of a common header and a This message is sent by the FE to the CE in response to the Config
message body consists of one or more TLVs describing the query message. It indicates whether the Config was successful or not on
result. Detailed description of the message is as below. the FE and also gives a detailed response regarding the configuration
result of each attribute.
Message transfer direction: Message transfer direction:
Current version limits the query response message transfer FE to CE
direction only from FE to CE.
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set MessageType= 'Config
'QueryResponse'. The ACK flag in the header SHOULD be set Response'. The ACK flag in the header is always ignored, because
'NoACK', meaning no further response for a query response message the config response message will never expect to get any more
is expected. If the ACK flag is set other values, the meaning of response from the message receiver (CE).
the flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the query message to be
responded, so that the query message sender can keep track of the
responses.
Message body: Message body:
The message body for a query response message consists of (at The Config response message body consists of one or more TLVs,
least) one or more than one TLVs that describe query results to the format of a single TLV is as follows:
individual queried entries. According to the queried information
being FE (coarse layer) information or LFB information as
described above, the response message body TLV has different data
format as below:
To respond to the query for FE (coarse layer) information, the
response TLV has following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type='FEQueryResponse' | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Response to Query Entry #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Response to Query Entry #2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Response to Query Entry #N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13
To respond to the query for LFB information, the response TLV has 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
data format as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type='LFBQueryResponse' | Length | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ID | Instance ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Response to Query Entry #1 ~ | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Response to Query Entry #2 ~ | Type = Operations (ADD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ | Operation Result | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Response to Query Entry #N ~ | |
~ Config Result ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Operations (DEL) | Length |
Figure 14
Response to Query Entry:
This is a TLV that describes the response to the queried entry,
as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Operation Result | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Description of Response to Query Entry ~ | |
~ Config Result ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 Figure 13
Type:
[Under discussion and TBD]
Description of Response to Query Entry:
This field presents the detailed description about the query
result of an entry. The encoding of the description is based on
the ForCES FE model if the entry is defined by FE model, or based
on vendor specifications if the entry is defined by vendors.
Note that the encoding is responsible for the 32 bits alignment
of the description field. When the query is successful, the
response result will include the information being queried. When
the query is failed, the response result will usually include the
information about the reason for the failure.
6.3 Configuration Messages Type (16 bits):
LFB Select.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
LFB Class ID (16 bits):
This field uniquely recognizes the LFB class/type.
LFB Instance ID (16 bits):
This field uniquely identifies the LFB instance.
Type (16 bits):
The operations are same as those defined for Config messages.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Operation Result (16 bits):
This indicates the overall result of the config operation,
whether it was successful or it failed.
Config Result (variable length):
This will carry LFB specific results (single or Array LFB
specific result entries). The config result might itself be of
the form of a TLV.
Editorial Note: If the approach of using an FE Protocol & FE Object 6.4 Query and Query Response Messages
is fully adopted and no other reason for having FE
TLVs is identified, then no distinction will be
further made in the TLV types between FE* and LFB*.
As a result, the Type ID and Instance ID in the TLV
will also be used to identify the FE Protocol
Object, with specific values as mentioned in Section
3.3.2
The ForCES Configuration messages are used by the CEs to configure The ForCES query and query response messages are used for one ForCES
the FEs in a ForCES NE and report the results back to the CE. element (CE or FE) to query other ForCES element(s) for various kinds
of information. Current version of ForCES protocol limits the use of
the messages only for CE to query information of FE.
6.3.1 Config Message 6.4.1 Query Message
This message is sent by the CE to the FE to configure FE or LFB As usual, a query message is composed of a common header and a
attributes. This message is also used by the CE to subscribe/ message body that consists of one or more TLV data format. Detailed
unsubscribe to FE, LFB events. description of the message is as below.
Message transfer direction: Message transfer direction:
CE to FE Current version limits the query message transfer direction only
from CE to FE.
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Config'. The The Message Type in the header is set to MessageType= 'Query'.
ACK flag in the header is can be used by the CE to turn off any The ACK flag in the header SHOULD be set 'ACKAll', meaning a full
response from the FE. The default behavior is to turn on the ACK response for a query message is always expected. If the ACK flag
to get the config response from the FE. is set other values, the meaning of the flag will then be
ignored, and a full response will still be returned by message
receiver.
Message body: Message body:
The Config message body consists of one or more TLVs, the format The query message body consists of (at least) one or more than
of a single (LFB) TLV is as follows: one TLVs that describe entries to be queried. The TLV is called
LFBselect TLV and the data format is as below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB Operations | Length | | Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved/ Event Type | Flags | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ID | Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config data | | Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 Figure 14
Editorial Note:
1. Under discussion is whether there is a need
for explicit multiple LFB insatance
addressing here. One way to realize it is
to define a specific Instance select TLV to
substitute above 'LFB Instance ID' field.
The TLV may have following format:
The format for a FE attributes TLV is as follows INSselectTLV := Type Length Value
Type := INSselect
Value := InstanceID (RangeMark | Instance ID)+
2. An applicable RangeMark is '0xffffffff', the
value of which is the same as Instance
broadcast ID. Because there will be no
broadcast address applied in this place,
there will be no worry of ambiguity here.
Operation TLV:
The Operation TLV for the 'Query' message is formatted as:
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 = FE operations | Length | | Type = GET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|Reserved/ Event Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config data | | Path(or Attribute ID?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16
Path(or Attribute ID?):
[Under discussion and TBD]
Editorial Note: There is a debate on whether we should use a
'Path' or simply an 'Attribute ID' or a 'Table
ID' here at the protocol layer. A Path is used
for data indexing for a table, while an
'Attribute ID' or a 'Table ID' only specify
which attribute or table to use, leaving table
index to be included in followed data.
Query Data:
[Under discussion and TBD]
To better understand the above PDU format, we can show a tree
structure for the format as below:
main hdr (type = Query)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = target LFB class
| |
| |
| +-- LFBInstance = target LFB instance
| |
| |
| +-- T = operation { GET }
| | |
| | +-- // one or more path targets
| | // under discussion
| +-- T = operation { GET }
| | |
| | +-- // one or more path targets
| |
Figure 17 Figure 17
Type (16 bits): 6.4.2 Query Response Message
This is a combination of FE, LFB attributes with operations. The
operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE,
UNSUBSCRIBE, CANCEL. The following Types are defined for this
TLV:
* FE Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe
events
* LFB Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe
events
For any of the FE attribute Types, the Type, and Instance ID
fields are not present in this TLV.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Flags (16 bits):
These can be used to indicate Atomicity, Batching, etc.
Type ID (16 bits):
This field uniquely recognizes the LFB type.
Instance ID (16 bits):
This field uniquely identifies the LFB instance.
Config Data (variable length):
This will carry LFB specific data (single or Array LFB specific
entries). The config data might itself be of the form of a TLV.
Event Type (16 bits):
For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field
will define the Events of interest. Examples of Event Type
include, All Events, FE Events, LFB Events, Packets, Packet
Mirroring.
6.3.2 Config Response Message When receiving a query message, the receiver should process 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
Message. The query result can be the information being queried if
the query operation is successful, or can also be error codes if the
query operation fails, indicating the reasons for the failure.
This message is sent by the FE to the CE in response to the Config A query response message is also composed of a common header and a
message. It indicates whether the Config was successful or not on message body consists of one or more TLVs describing the query
the FE and also gives a detailed response regarding the configuration result. Detailed description of the message is as below.
result of each attribute.
Message transfer direction: Message transfer direction:
FE to CE Current version limits the query response message transfer
direction only from FE to CE.
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Config The Message Type in the header is set to MessageType=
Response'. The ACK flag in the header is always ignored, because 'QueryResponse'. The ACK flag in the header SHOULD be set
the config response message will never expect to get any more 'NoACK', meaning no further response for a query response message
response from the message receiver (CE). is expected. If the ACK flag is set other values, the meaning of
the flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the query message to be
responded, so that the query message sender can keep track of the
responses.
Message body: Message body:
The Config response message body consists of one or more TLVs, The message body for a query response message consists of (at
the format of a single TLV is as follows: least) one or more than one TLVs that describe query results for
individual queried entries. The TLV is also called LFBselect
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, and has exactly the same data format as query message,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ except the Operation TLV inside is different. The order of the
| Type = LFB Operations | Length | TLV here matches the TLVs in the corresponding Query message, and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the TLV number should keep the same. The Operation TLV here is a
| Overall Result | reserved | 'GET-RESPONSE' TLV and the data is 'Query Response Data', as
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ below:
| Type ID | Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Result |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for a FE response TLV is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = FE operations | Length | | Type = GET-RESPOSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Overall Result | reserved | | Path(or Attribute ID?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Result | | Query Response Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 Figure 18
Type (16 bits): Query Response Data:
Same as that for Config message. For any of the FE attribute [Under discussion and TBD]
Types, the Type, and Instance ID fields are not present in this
TLV.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Overall Result (16 bits):
This indicates the overall result of the config message, whether
it was successful or it failed.
Type ID (16 bits):
This field uniquely recognizes the LFB type.
Instance ID (16 bits):
This field uniquely identifies the LFB instance.
Config Result (variable length):
This will carry LFB specific results (single or Array LFB
specific result entries). The config result might itself be of
the form of a TLV.
6.4 Event Notification and Response Messages 6.5 Event Notification and Response Messages
Editorial Note: If the approach of using an FE Protocol & FE Object
is fully adopted and no other reason for having FE
TLVs is identified, then no distinction will be
further made in the TLV types between FE* and LFB*.
As a result, the Type ID and Instance ID in the TLV
will also be used to identify the FE Protocol
Object, with specific values as mentioned in Section
3.3.2
The Event Notification Message is used for one ForCES element to The Event Notification Message is used for one ForCES element to
asynchronously notify one or more other ForCES elements in the same asynchronously notify one or more other ForCES elements in the same
ForCES NE on just happened events in it. The Event Notification ForCES NE on just happened events in it. The Event Notification
Response Message is used for the receiver of the Event Notification Response Message is used for the receiver of the Event Notification
Message to acknowledge the reception of the event notification. Message to acknowledge the reception of the event notification.
Events in current ForCES protocol can be categorized into following Events in current ForCES protocol can be categorized into following
three types: types:
o Events happened in CE o Events happened in CE
o Events happened in FE at the FE coarse layer (in FE protocol o Events happened in FE
object and FE object)
o Events happened in LFB inside an FE
Events can also be categorized into two classes according to whether Events can also be categorized into two classes according to whether
they need subscription or not. An event in one ForCES element that they need subscription or not. An event in one ForCES element that
needs to be subscribed will send notifications to other ForCES needs to be subscribed will send notifications to other ForCES
elements only when the other elements have subscribed to the element elements only when the other elements have subscribed to the element
for the event notification. How to subscribe/unsubscribe for an for the event notification. How to subscribe/unsubscribe for an
event is described in the Configure Message in Section 6.3. An event event is described in the Configure Message in Section 6.3. An event
that needs not to be subscribed will always send notifications to that needs not to be subscribed will always send notifications to
other ForCES elements when the event happens. An event definition other ForCES elements when the event happens. An event definition
made by ForCES FE model or by vendors will state if the event needs made by ForCES protocol, ForCES FE model, or by vendors will state if
subscription or not. the event needs subscription or not.
Editorial Note: There is an argument that it is preferable to have Editorial Note: There is an argument that it is preferable to have
all events subscribable. all events subscribable.
6.4.1 Event Notification Message 6.5.1 Event Notification Message
As usual, an Event Notification Message is composed of a common As usual, an Event Notification Message is composed of a common
header and a message body that consists of one or more TLV data header and a message body that consists of one or more TLV data
format. Detailed description of the message is as below. format. Detailed description of the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE, 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 The Message Type in the message header is set to
MessageType = 'EventNotification'. The ACK flag in the header can MessageType = 'EventNotification'. The ACK flag in the header can
be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'.
skipping to change at page 36, line 4 skipping to change at page 38, line 28
As usual, an Event Notification Message is composed of a common As usual, an Event Notification Message is composed of a common
header and a message body that consists of one or more TLV data header and a message body that consists of one or more TLV data
format. Detailed description of the message is as below. format. Detailed description of the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE, 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 The Message Type in the message header is set to
MessageType = 'EventNotification'. The ACK flag in the header can MessageType = 'EventNotification'. The ACK flag in the header can
be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'.
Note that the 'Success' here only means the receiver of the Note that the 'Success' here only means the receiver of the
message has successfully received the message. message has successfully received the message.
Message Body: Message Body:
The message body for an event notification message consists of (at The message body for an event notification message consists of (at
least) one or more than one TLVs that describe the notified least) one or more than one TLVs that describe the notified
events. events. The TLV is defined as follows:
According to the different event types described above, the
message body TLV has different data format, which is defined as
follows:
For events generated by CE or by FE coarse layer, the TLV has
following data format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type='FEEventNotification' | Length |
| or 'CEEventNotification' | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Event #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Event #2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Event #N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For events generated by LFB in FE, the TLV has data format as:
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='LFBEventNotification' | Length | | Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ID | Instance ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Event #1 ~ | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Event #2 ~ | Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Event #N ~ | Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19 Figure 19
Event:
Operation TLV:
This is a TLV that describes the event to be notified, as follows: This is a TLV that describes the event to be notified, as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Description of Event ~ | Path(or Event ID?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20 Figure 20
Type: Path(or Event ID):
[TBD] [Under discussion and TBD]
Description of Event: Event Data:
This field will make a detailed description of the happened event. [Under discussion and TBD]
The encoding of the description is based on the ForCES FE model if
the event is defined by FE model, or based on vendor
specifications if the event is defined by vendors. Note that the
encoding is responsible for the 32 bits alignment of the
description field.The description will usually include the name
(or the name ID) of the event. It may also include some other
information like parameters that are related to the happened
event.
6.4.2 Event Notification Response Message To better understand the above PDU format, we can show a tree
structure for the format as below:
main hdr (type = Event Notification)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = target LFB class
| |
| |
| +-- LFBInstance = target LFB instance
| |
| |
| +-- T = operation { REPORT }
| | |
| | +-- // one or more path targets
| | // under discussion
| +-- T = operation { REPORT }
| | |
| | +-- // one or more path targets
| |
Figure 21
6.5.2 Event Notification Response Message
After sending out an Event Notification Message, the sender may be After sending out an Event Notification Message, the sender may be
interested in ensuring that the message has been received by interested in ensuring that the message has been received by
receivers, especially when the sender thinks the event notification receivers, especially when the sender thinks the event notification
is vital for system management. An Event Notification Response is vital for system management. An Event Notification Response
Message is used for this purpose. The ACK flag in the Event Message is used for this purpose. The ACK flag in the Event
Notification Message header are used to signal if such acknowledge is Notification Message header are used to signal if such acknowledge is
requested or not by the sender. requested or not by the sender.
Detailed description of the message is as below: Detailed description of the message is as below:
skipping to change at page 38, line 4 skipping to change at page 40, line 28
the Event Notification Message that it responses. the Event Notification Message that it responses.
Message Header: Message Header:
The Message Type in the header is set MessageType= The Message Type in the header is set MessageType=
'EventNotificationResponse'. The ACK flag in the header SHOULD be 'EventNotificationResponse'. The ACK flag in the header SHOULD be
set 'NoACK', meaning no further response for the message is set 'NoACK', meaning no further response for the message is
expected. If the ACK flag is set other values, the meaning of the expected. If the ACK flag is set other values, the meaning of the
flag will then be ignored. The Sequence Number in the header flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the message to be responded, so SHOULD keep the same as that of the message to be responded, so
that the event notificatin message sender can keep track of the that the event notificatin message sender can keep track of the
responses. responses.
Message Body:
This contains a TLV that describe the response result as below: The message body for an event notification response message
consists of (at least) one or more than one TLVs that describe the
notified events. The TLV is also called LFBselect TLV, and has
exactly the same data format as Event Notification Message, except
the Operation TLV inside is different. The order of the TLV here
matches the TLVs in the corresponding Event Message, and the TLV
number should keep the same. The Operation TLV here is a
'REPORT-RESPONSE' TLV and the data is 'Event Response Data', as
below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type='ResponseResult' | Length | | Type = REPORT-RESPONSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Event ID?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | Reason | Code | | Result | Reason | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21 Figure 22
Path(or Event ID?):
[Under discussion and TBD]
Result: Result:
This describes the reception result of the event notification This describes the reception result of the event notification
message as below: message as below:
Result Value Meaning Result Value Meaning
'Success' The event has been successfully received. 'Success' The event has been successfully received.
'Unsuccess' The event has not been successfully received. 'Unsuccess' The event has not been successfully received.
Reason, Code: Reason, Code:
This describes the reason and possible error code when the message This describes the reason and possible error code when the message
is not successfully received. Note that only the failure at the is not successfully received. Note that only the failure at the
protocol layer rather than the transport layer can be allocated protocol layer rather than the transport layer can be handled
here, that is, if even the header part of the message to be here, that is, if even the header part of the message to be
responded can not be correctly received, the response to the responded can not be correctly received, the response to the
message will not be able to be generated by the receiver. message will not be able to be generated by the receiver.
Editorial Note: There is a debate on whether the Event Editorial Note: There is a debate on whether the Event
Notification Response Message is necessary or Notification Response Message is necessary or
not. The pro for it is some event notification not. The pro for it is some event notification
senders may be interested in knowing if receivers senders may be interested in knowing if receivers
have had success/unsuccess receptions of the have had success/unsuccess receptions of the
events or not. An alternative to generate such events or not. An alternative to generate such
response is for the protocol to define a response is for the protocol to define a
universal ACK message so that it can act as universal ACK message so that it can act as
responses for any types of messages as well as responses for any types of messages as well as
the event notification messages, when the message the event notification messages, when the message
senders are interested in knowing whether the senders are interested in knowing whether the
messages have been successfully received or not messages have been successfully received or not
(different from the responses for the message (different from the responses for the message
processing results). processing results).
6.5 Packet Redirect Message 6.6 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 associated with some metadata generated by other LFBs in sometimes associated with some metadata generated by other LFBs in
the model, or they may occasionally be other protocol packets, which the model, or they may occasionally be other protocol packets, which
usually happen when CE and FE are jointly implementing some usually happen 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
packets that need high-touch operations in CE. Packets redirected packets that need high-touch operations in CE,or packets for which
from CE to FE are the data packets that are generated by CE and are the IP destination address is the NE. Packets redirected from CE to
decided by CE to put into forwarding plane in FE. FE are the data packets that come from the CE and are decided by CE
to put into forwarding plane in FE.
Supplying such a redirect path between CE and FE actually leads to a
possibility of this path being DoS attacked. Attackers may
maliciously try to send huge spurious packets that will be redirected
by FE to CE, making the redirect path been congested. ForCES
protocol and the TML layer will jointly supply approaches to prevent
such DoS attack. To define a specific 'Packet Redirect Message'
makes TML and CE able to distinguish the redirect messages from other
ForCES protocol messages.
By properly configuring related LFBs in FE, a packet can also be By properly configuring related LFBs in FE, a packet can also be
mirrored to CE instead of purely redirected to CE, i.e., the packet mirrored to CE instead of purely redirected to CE, i.e., the packet
is duplicated and one is redirected to CE and the other continues its is duplicated and one is redirected to CE and the other continues its
way in the LFB topology. way in the LFB topology.
Editorial Note: There are also discussions on how LFBs in FE model Editorial Note: There are also discussions on how LFBs in FE model
that are related to packet redirect operations that are related to packet redirect operations
should be defined. Although it is out of the scope should be defined. Although it is out of the scope
of forces protocol, how to define the LFBs affect of forces protocol, how to define the LFBs affect
skipping to change at page 40, line 19 skipping to change at page 43, line 21
datapath as follows: datapath as follows:
+-----------------+ +-----------+ +-----------------+ +-----------+
| RedirectTap LFB |------>| | | RedirectTap LFB |------>| |
+-----------------+ | | +-----------------+ | |
| Scheduler | | Scheduler |
From other LFB ---->| LFB | From other LFB ---->| LFB |
| | | |
+-----------+ +-----------+
Figure 23 Figure 24
By use of several 'RedirectSink' LFBs and several By use of several 'RedirectSink' LFBs and several
'RedirectTap' LFBs that connect to several different 'RedirectTap' LFBs that connect to several different
datapaths in FE forwarding plane, multiple packet datapaths in FE forwarding plane, multiple packet
redirect paths between CE and FE can be constructed. redirect paths between CE and FE can be constructed.
Thought 2: There might be another way a packet could be Thought 2: There might be another way a packet could be
redirected: directly by a forwarding path, e.g., by redirected: directly by a forwarding path, e.g., by
FPGA/ASIC/NP microcode. In such a case we do not FPGA/ASIC/NP microcode. In such a case we do not
need to put in a lot of smartness. Probably a link need to put in a lot of smartness. Probably a link
skipping to change at page 41, line 9 skipping to change at page 44, line 9
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set to MessageType=
'PacketRedirect'. The ACK flags in the header SHOULD be set 'PacketRedirect'. The ACK flags in the header SHOULD be set
'NoACK', meaning no response is expected by this message. If the 'NoACK', meaning no response is expected by this message. If the
ACK flag is set other values, the meanings will be ignored. ACK flag is set other values, the meanings will be ignored.
Message Body: Message Body:
Consists of one or more TLVs, with every TLV having the following Consists of one or more TLVs, with every TLV having the following
data format: data format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type='RedirectData' | Length | | Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ID | Instance ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Data #1 ~ | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Data #2 ~ | Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Data #N ~ | Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24 Figure 25
Type ID: LFB class ID:
There are only two possible LFB types here, the 'RedirectSink' LFB There are only two possible LFB classes here, the 'RedirectSink'
or the 'RedirectTap' LFB. If the message is from FE to CE, the LFB or the 'RedirectTap' LFB. If the message is from FE to CE,
LFB type should be 'RedirectSink'. If the message is from CE to the LFB class should be 'RedirectSink'. If the message is from CE
FE, the LFB type should be 'RedirectTap'. to FE, the LFB class should be 'RedirectTap'.
Instance ID: Instance ID:
Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB.
Redirected Data: Operation 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
specified LFB above. The order of the data number is also the specified LFB above. The order of the data number is also the
order the data packet arrives the redirector LFB, that is, the order the data packet arrives the redirector LFB, that is, the
Redirected Data #1 should arrive earlier than the Redirected Data Redirected Data #1 should arrive earlier than the Redirected Data
#2 in this redirector LFB. The TLV format is as follows: #2 in this redirector LFB. The TLV format is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type = PAYLOAD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Description of Redirected Data ~ | Path(or Sequence Number?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25 Figure 26
Path(or Sequence Number?):
[Under discussion and TBD]
Type: Type:
[TBD] [TBD]
Description of Redirected Data: Redirected Data:
This field will make a detailed description of the data to be This field will make a detailed description of the data to be
redirected as well as the data itself. The encoding of the redirected as well as the data itself. The encoding of the
description is based on the ForCES FE model if the redirector LFB description is based on the ForCES FE model if the redirector LFB
is defined by FE model, or based on vendor specifications if the is defined by FE model, or based on vendor specifications if the
redirector LFB is defined by vendors. The description will redirector LFB is defined by vendors. The description will
usually include the name (or the name ID) of the redirected packet usually include the name (or the name ID) of the redirected packet
data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data
itself. It may also include some metadata (metadata name (or name itself. It may also include some metadata (metadata name (or name
ID) and its value)associated with the redirected data packet. ID) and its value)associated with the redirected data packet.
6.6 State Maintenance Messages
The State Maintenance Messages are used by the CE to change state
related information on the FE.
Editorial Note: As work progresses in defining the FE model, it may
happen that the messages defined here (State
Maintenance messages) become redundant. For
instance, FE activation/deactivation may be
performed by configuring the FE State attribute in
the FE Object. Such inconsistencies will be
resolved
6.6.1 State Maintenance Message
This message is sent by the CE to change the state of the FE, e.g.
to Activate/Deactivate the FE, shutdown the FE, etc.
Message transfer direction:
CE to FE
Message Header:
The Message Type in the header is set MessageType= 'State
Maintenance'. The ACK flag in the header is can be used by the
CE to turn off any response from the FE. The default behavior is
to turn on the ACK to get the state maintenance response from the
FE.
Message body:
The state maintenance message body consists of one or more TLVs,
the format of a single TLV is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type= FE De/Activate,Shutdown | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26
Type (16 bits):
These can be FE Activate, FE Deactivate, Shutdown FE. Activating
an FE means asking it to forward packets, Deactivate means the FE
stops forwarding packets. The default state of the FE is
deactivated till it explicitly activated by the CE.
Editorial Note: These Types may be extended to include LFB
Activate/Deactivate as well. However this is
still being discussed.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
FE State object (variable):
This is an TLV which can be defined and extended to represent FE
specific state information. It will contain information such as
the HA Mode, Primary CE ID, etc for the FE.
6.6.2 State Maintenance Response Message
This message is sent by the FE to the CE in response to the state m.
message. It indicates whether the state m. was successful or not on
the FE.
Message transfer direction:
FE to CE
Message Header:
The Message Type in the header is set MessageType= 'state m.
Response'. The ACK flag in the header is always ignored, because
the state m. response message will never expect to get any more
response from the message receiver (CE).
Message body:
The state maintenance response message body consists of one or
more TLVs, the format of a single TLV is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type= S.M.Result | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27
Type (16 bits):
Same as that for state maintenance message.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Overall Result (16 bits):
This indicates the overall result of the state maintenance
message, whether it was successful or it failed.
6.7 Heartbeat Message 6.7 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.
A Heartbeat Message is sent by a ForCES element periodically. The A Heartbeat Message is sent by a ForCES element periodically. The
time interval to send the message is set by the Association Setup time interval to send the message is set by the Association Setup
Message described in Section 6.1.1. A little different from other Message described in Section 6.1.1. A little different from other
protocol messages, a Heartbeat messge is only composed of a common protocol messages, a Heartbeat message is only composed of a common
header, withe the message body left empty. Detailed description of header, withe 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'. The ACK flag in the header SHOULD be set to 'Heartbeat'. The ACK flag in the header SHOULD be set to
'NoACK', meaning no response from receiver(s) is expected by the 'NoACK', meaning no response from receiver(s) is expected by the
message sender. Other values of the ACK flag will always be message sender. Other values of the ACK flag will always be
ignored by the message receiver. ignored by the message receiver.
Message Body: Message Body:
The message body is empty for the Heartbeat Message, so as to The message body is empty for the Heartbeat Message.
grasp more efficiency for message transportation and processing.
6.8 Operation Summary
The following tables summarize the operations and their applicabiity
to the messages.
No Operations for the following messages:
Assoc-Setup
Assoc-Setup-Resp
Assoc-Teardown
Heartbeat
+-------------------+-------+------------+--------+-------------+
| Operation | Query | Query-Resp | Config | config-Resp |
+-------------------+-------+------------+--------+-------------+
| Set | | | X | X |
| | | | | |
| Delete | | | X | X |
| | | | | |
| Update | | | X | X |
| | | | | |
| Get | X | X | | |
| | | | | |
| Event subscribe | | | X | X |
| | | | | |
| Event unsubscribe | | | X | X |
+-------------------+-------+------------+--------+-------------+
+-----------+--------------+-------------+------------------+
| Operation | Packet-Redir | Event-Notif | Event-Notif-Resp |
+-----------+--------------+-------------+------------------+
| Payload | X | | |
| | | | |
| Event | | X | X |
+-----------+--------------+-------------+------------------+
7. Protocol Scenarios 7. Protocol Scenarios
7.1 Association Setup state 7.1 Association Setup state
The associations among CEs and FEs are initiated via Association The associations among CEs and FEs are initiated via Association
setup message from the FE. If a setup request is granted by the CE, setup message from the FE. If a setup request is granted by the CE,
a successful setup response message is sent to the FE. If CEs and a successful setup response message is sent to the FE. If CEs and
FEs are operating in an insecure environment then the security FEs are operating in an insecure environment then the security
association have to be established between them before any association have to be established between them before any
skipping to change at page 46, line 29 skipping to change at page 48, line 29
| | | |
| Topo Query | | Topo Query |
|<----------------------| |<----------------------|
| | | |
| Topo Query Resp | | Topo Query Resp |
|---------------------->| |---------------------->|
| | | |
| FE UP Event | | FE UP Event |
|---------------------->| |---------------------->|
| | | |
| S.M. Activate FE | | Config-Activate FE |
|<----------------------| |<----------------------|
| | | |
Figure 28: Message exchange between CE and FE to establish an NE Figure 27: Message exchange between CE and FE to establish an NE
association association
On successful completion of this state, the FE joins the NE and is On successful completion of this state, the FE joins the NE and is
moved to the Established State or Steady state. moved to the Established State or Steady state.
7.2 Association Established state or Steady State 7.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
skipping to change at page 47, line 45 skipping to change at page 49, line 45
|---------------------->| |---------------------->|
| | | |
| Packet Redirect | | Packet Redirect |
|---------------------->| |---------------------->|
| | | |
| Heart Beat | | Heart Beat |
|<----------------------| |<----------------------|
. . . .
. . . .
| | | |
| S.M. FE Deactivate | | Config-Activate FE |
|<----------------------| |<----------------------|
| | | |
Figure 29: Message exchange between CE and FE during steady-state Figure 28: 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.
8. High Availability Support 8. High Availability Support
Editorial Note: This section currently focuses only on CE-CE
redundancy. We need to further discuss the FE-FE
view. We also need to discuss Multiple Primary CEs.
The ForCES protocol provides mechanisms for CE redundancy and The ForCES protocol provides mechanisms for CE redundancy and
failover, in order to support High Availability. There can be failover, in order to support High Availability as defined in
multiple redundant CEs and FEs in a ForCES NE. However, at any time [RFC3654]. FE redundancy and FE to FE interaction is currently out
there can only be one Primary CE controlling the FEs and there can be of scope of this draft. There can be multiple redundant CEs and FEs
multiple secondary CEs. The FE and the CE PL are aware of the in a ForCES NE. However, at any time there can only be one Primary
primary and secondary CEs. This information (primary, secondary CEs) CE controlling the FEs and there can be multiple secondary CEs. The
is configured in the FE, CE PLs during pre-association by FEM, CEM FE and the CE PL are aware of the primary and secondary CEs. This
respectively. Only the primary CE sends Control messages to the FEs. information (primary, secondary CEs) is configured in the FE, CE PLs
The FE may send its event reports, redirection packets to only the during pre-association by FEM, CEM respectively. Only the primary CE
Primary CE (Report Primary Mode) or it may send these to both primary sends Control messages to the FEs. The FE may send its event
and secondary CEs (Report All Mode). (The latter helps with keeping reports, redirection packets to only the Primary CE (Report Primary
state between CEs synchronized, although it does not guarantee Mode) or it may send these to both primary and secondary CEs (Report
synchronization.) This behavior or HA Modes are configured during All Mode). (The latter helps with keeping state between CEs
Association setup phase but can be changed by the CE anytime during synchronized, although it does not guarantee synchronization.) This
protocol operation. A CE-to-CE synchronization protocol will be behavior or HA Modes are configured during Association setup phase
needed in most cases to support fast failover, however this will not but can be changed by the CE anytime during protocol operation. A
be defined by the ForCES protocol. CE-to-CE synchronization protocol will be needed in most cases to
support fast failover, however this will not be defined by the ForCES
protocol.
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), the TML on the FE
will trigger the FE PL regarding this failure. The FE PL will send a will trigger the FE PL regarding this failure. This can also be
message (Event Report) to the Secondary CEs to indicate this failure detected using the HB messages between FEs and CEs. The FE PL will
or the CE PL will detect this and one of the Secondary CEs takes over send a message (Event Report) to the Secondary CEs to indicate this
as the primary CE for the FE. An explicit message (State Maintenance failure or the CE PL will detect this and one of the Secondary CEs
Move command) from the primary CE, can also be used to change the takes over as the primary CE for the FE. During this phase, if the
Primary CE for an FE during normal protocol operation. In order to original primary CE comes alive and starts sending any commands to
support fast failover, the FE will establish association (setup msg) the FE, the FE should ignore those messages and send an Event to all
as well as complete the capability exchange with the Primary as well CEs indicating its change in Primary CE. Thus the FE only has one
as all the Secondary CEs (in all scenarios/modes). primary CE at a time.
An explicit message (Config message- Move command) from the primary
CE, can also be used to change the Primary CE for an FE during normal
protocol operation. In order to support fast failover, the FE will
establish association (setup msg) as well as complete the capability
exchange with the Primary as well as all the Secondary CEs (in all
scenarios/modes).
These two scenarios (Report All, Report Primary) have been These two scenarios (Report All, Report Primary) have been
illustrated in the figures below. illustrated in the figures 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 | | Asso Estb,Caps|exchange |
skipping to change at page 50, line 30 skipping to change at page 52, line 30
4 |-----------------------|------------------->| 4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 5 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |------------------------------------------->| 6 |------------------------------------------->|
Figure 30: CE Failover for Report All mode Figure 29: CE Failover for Report All 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 | | Asso Estb,Caps|exchange |
2 |<----------------------|------------------->| 2 |<----------------------|------------------->|
| | | | | |
| All msgs | | | All msgs | |
3 |<--------------------->| | 3 |<--------------------->| |
skipping to change at page 51, line 26 skipping to change at page 53, line 26
4 |-----------------------|------------------->| 4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 5 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |------------------------------------------->| 6 |------------------------------------------->|
Figure 31: CE Failover for Report Primary Mode Figure 30: CE Failover for Report Primary Mode
8.1 Responsibilities for HA 8.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 managements. 2. The TML also controls peer HA managements.
At this level, control of all lower layers example transport level At this level, control of all lower layers, for example transport
(such as IP addresses, MAC addresses etc) and associated links going level (such as IP addresses, MAC addresses etc) and associated links
down are the role of the TML. going down are the role of the TML.
PL Level: PL Level:
All the other functionality including configuring the HA behavior All the other functionality including configuring the HA behavior
during setup, the CEIDs are used to identify primary, secondary CEs, during setup, the CEIDs are used to identify primary, secondary CEs,
protocol Messages used to report CE failure (Event Report), Heartbeat protocol Messages used to report CE failure (Event Report), Heartbeat
messages used to detect association failure, messages to change messages used to detect association failure, messages to change
primary CE (state maintenance move), and other HA related operations primary CE (config - move), and other HA related operations described
described before are the PL responsibility. before are the PL responsibility.
To put the two together, if a path to a primary CE is down, the TML To put the two together, if a path to a primary CE is down, the TML
would take care of failing over to a backup path, if one is would take care of failing over to a backup path, if one is
available. If the CE is totally unreachable then the PL would be available. If the CE is totally unreachable then the PL would be
informed and it will take the appropriate actions described before. informed and it will take the appropriate actions described before.
9. Security Considerations 9. Security Considerations
ForCES architecture identified several [Reference Arch] levels of ForCES architecture identified several [Reference Arch] levels of
security. ForCES PL uses security services provided by the ForCES security. ForCES PL uses security services provided by the ForCES
skipping to change at page 55, line 5 skipping to change at page 57, line 5
9.2.2 Message authentication service 9.2.2 Message authentication service
This is TML specific operation and is transparent to ForCES PL This is TML specific operation and is transparent to ForCES PL
layer[TML document]. layer[TML document].
9.2.3 Confidentiality service 9.2.3 Confidentiality service
This is TML specific operation and is transparent to ForCES PL This is TML specific operation and is transparent to ForCES PL
layer.[TML document] layer.[TML document]
10. References 10. Acknowledgments
10.1 Normative References The authors of this draft would like to acknowledge and thank the
following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes,
Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering,
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.
11. References
11.1 Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003. of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
10.2 Informational References 11.2 Informational References
[FE-MODEL] [FE-MODEL]
Yang, L., "ForCES Forwarding Element Model", Feb. 2004. Yang, L., "ForCES Forwarding Element Model", Feb. 2004.
Author's Address Author's Address
Avri Doria Avri Doria
ETRI ETRI
Phone: +1 401 663 5024 Phone: +1 401 663 5024
EMail: avri@acm.org EMail: avri@acm.org
Appendix A. Individual Authors/Editors Contact Appendix A. Individual Authors/Editors Contact
The participants in the ForCES Protocol Team: Ligang Dong
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-88071024
EMail: donglg@mail.hzic.edu.cn
+--------------------+------------------------------+ Avri Doria
| Author | Email | ETRI
+--------------------+------------------------------+ EMail: avri@acm.org
| Ligang Dong | donglg@mail.hzic.edu.cn |
| | |
| Avri Doria | avri@acm.org |
| | |
| Ram Gopal | ram.gopal@nokia.com |
| | |
| Robert Haas | rha@zurich.ibm.com |
| | |
| Jamal Hadi Salim | hadi@znyx.com |
| | |
| Hormuzd M Khosravi | hormuzd.m.khosravi@intel.com |
| | |
| Weiming Wang | wmwang@mail.hzic.edu.cn |
+--------------------+------------------------------+
Table 1 Ram Gopal
Nokia
5, Wayside Road
Burlington MA 01803
USA
Phone: 1-781-993-3685
EMail: ram.gopal@nokia.com
Robert Haas
IBM
Saumerstrasse 4
8803 Ruschlikon
Switzerland
EMail: rha@zurich.ibm.com
Jamal Hadi Salim
Znyx
Ottawa, Ontario
Canada
EMail: hadi@znyx.com
Hormuzd M Khosravi
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com
Weiming Wang
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-88057712
EMail: wmwang@mail.hzic.edu.cn
Appendix B. IANA considerations Appendix B. IANA considerations
tbd tbd
Appendix C. Implementation Notes Appendix C. Implementation Notes
C.1 TML considerations C.1 TML considerations
Having separated the PL from the TML layer, it became clear that the Having separated the PL from the TML layer, it became clear that the
skipping to change at page 60, line 4 skipping to change at page 64, line 4
C.1.2 Message type inference to Mapping at the TML C.1.2 Message type inference to Mapping at the TML
In this case one would define the desires of the different message In this case one would define the desires of the different message
types and what they expect from the TML. For example: types and what they expect from the TML. For example:
1. Association Setup, Teardown, Config, Query the PL will expect the 1. Association Setup, Teardown, Config, Query the PL will expect the
following services from TML: Reliable delivery and highest following services from TML: Reliable delivery and highest
prioritization. prioritization.
2. Packet Redirect, HB Message Types, and Event Reports the PL will 2. Packet Redirect, HB Message Types, and Event Reports the PL will
require the following services from TML: Medium Prioritization, require the following services from TML: Medium Prioritization,
and notifications when excessive losses are reached. and notifications when excessive losses are reached.
Appendix D. Changes between -00 and -01
1. Major Protocol changes
* Restructured message format to apply operation to LFB as
opposed to having operation be the primary organizing
principle
* Worked with model team to bring the draft into harmony with
their model approach
2. Document changes
* Replaced FE protocol Object and FE Object sections with
combined section on FE, CE and FE protocol LFBs
* Removed minor version id
* Added Header flags
* Added BNF description of message structure
* Added tree structure description of PDUs
* Added section on each type of LFB
* Added structural description of each message
* Moved query messages section to come after config message
section
* Replace state maintenance section
* Added section with tables showing the operations relevant to
particular messages
* Many spelling and grammatical corrections
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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