RFC 5810
Forwarding and Control Element Separation (ForCES) Protocol Specification
7.2. Protocol Encoding Visualization
The figure below shows a general layout of the PL PDU. A main header is followed by one or more LFB selections each of which may contain one or more operations.
main hdr (Config in this case) | | +--- T = LFBselect | | | +-- LFBCLASSID | | | | | +-- LFBInstance | | | +-- T = SET | | | | | +-- // one or more path targets | | // with their data here to be added | | | +-- T = DEL | . | | . +-- // one or more path targets to be deleted | | +--- T = LFBselect | | | +-- LFBCLASSID | | | | | +-- LFBInstance | | | + -- T= SET | | . | | . | + -- T= DEL | | . | | . | | | + -- T= SET | | . | | . | | +--- T = LFBselect | +-- LFBCLASSID | +-- LFBInstance . . . Figure 21: PL PDU Logical Layout
The figure below shows a more detailed example of the general layout
of the operation within a targeted LFB selection. The idea is to
show the different nesting levels a path could take to get to the
target path.
T = SET
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| + -- T = KEYINFO-TLV
| | + -- KEY_ID
| | + -- KEY_DATA
| |
| + -- T = FULLDATA-TLV
| + -- data
|
|
T = SET
| |
| +- T = Path-data
| | |
| | + -- flags
| | + -- IDCount
| | + -- IDs
| | |
| | + -- T = FULLDATA-TLV
| | + -- data
| +- T = Path-data
| |
| + -- flags | + -- IDCount | + -- IDs | | | + -- T = FULLDATA-TLV | + -- data T = DEL | +- T = Path-data | + -- flags + -- IDCount + -- IDs | +- T = Path-data | + -- flags + -- IDCount + -- IDs | +- T = Path-data | + -- flags + -- IDCount + -- IDs + -- T = KEYINFO-TLV | + -- KEY_ID | + -- KEY_DATA +- T = Path-data | + -- flags + -- IDCount + -- IDs Figure 22: Sample Operation Layout Appendix D shows a more concise set of use cases on how the data encoding is done.7.3. Core ForCES LFBs
There are two LFBs that are used to control the operation of the ForCES protocol and to interact with FEs and CEs: o FE Protocol LFB
o FE Object 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 components 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.7.3.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 0x2. The FE Protocol LFB Instance ID is assigned the value 0x1. There MUST be one and only one instance of the FE Protocol LFB in an FE. The values of the components in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for correct operation of the protocol. The formal definition of the FE Protocol Object LFB can be found in Appendix B.7.3.1.1. FE Protocol Capabilities
FE Protocol capabilities are read-only.7.3.1.1.1. SupportableVersions
ForCES protocol version(s) supported by the FE.7.3.1.1.2. FE Protocol Components
FE Protocol components (can be read and set).7.3.1.1.2.1. CurrentRunningVersion Current running version of the ForCES protocol.
7.3.1.1.2.2. FEID FE unicast ID.7.3.1.1.2.3. MulticastFEIDs FE multicast ID(s) list - This is a list of multicast IDs to which the FE belongs. These IDs are configured by the CE.7.3.1.1.2.4. CEHBPolicy CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat Dead Interval (CE HDI)' as described below, defines the operating parameters for the FE to check the CE liveness. The policy values with meanings are listed as follows: o 0 (default) - This policy specifies that the CE will send a Heartbeat message to the FE(s) whenever the CE reaches a time interval within which no other PL messages were sent from the CE to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. The CE HDI component as described below is tied to this policy. o 1 - The CE will not generate any HB messages. This actually means that the CE does not want the FE to check the CE liveness. o Others - Reserved.7.3.1.1.2.5. CEHDI CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses to check the CE liveness. If FE has not received any messages from CE within this time interval, FE deduces lost connectivity, which implies that the CE is dead or the association to the CE is lost. Default value is 30 s.7.3.1.1.2.6. FEHBPolicy FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat Interval (FE HI)', defines the operating parameters for how the FE should behave so that the CE can deduce its liveness. The policy values and the meanings are: o 0 (default) - The FE should not generate any Heartbeat messages. In this scenario, the CE is responsible for checking FE liveness by setting the PL header ACK flag of the message it sends to AlwaysACK. The FE responds to the CE whenever the CE sends such Heartbeat Request messages. Refer to Section 7.10 and Section 4.3.3 for details.
o 1 - This policy specifies that the FE MUST actively send a
Heartbeat message if it reaches the time interval assigned by the
FE HI as long as no other messages were sent from the FE to the CE
during that interval as described in Section 4.3.3.
o Others - Reserved.
7.3.1.1.2.7. FEHI
FE Heartbeat Interval (FE HI) - The time interval the FE should use
to send HB as long as no other messages were sent from the FE to the
CE during that interval as described in Section 4.3.3. The default
value for an FE HI is 500 ms.
7.3.1.1.2.8. CEID
Primary CEID - The CEID with which the FE is associated.
7.3.1.1.2.9. LastCEID
Last Primary CEID - The CEID of the last CE with which the FE
associated. This CE ID is reported to the new Primary CEID.
7.3.1.1.2.10. BackupCEs
The list of backup CEs an FE can use as backups. Refer to Section 8
for details.
7.3.1.1.2.11. CEFailoverPolicy
CE failover policy - This specifies the behavior of the FE when the
association with the CE is lost. There is a very tight relation
between CE failover policy and Section 7.3.1.1.2.8,
Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an
association is lost, depending on configuration, one of the policies
listed below is activated.
o 0 (default) - The FE should stop functioning immediately and
transition to FE OperDisable.
o 1 - The FE should continue running and do what it can even without
an associated CE. This basically requires that the FE support CE
Graceful restart (and defines such support in its capabilities).
If the CEFTI expires before the FE re-associates with either the
primary CEID (Section 7.3.1.1.2.8) or one of possibly several
backup CEs (Section 7.3.1.1.2.10), the FE will go operationally
down.
o Others - Reserved.7.3.1.1.2.12. CEFTI CE Failover Timeout Interval (CEFTI) - The time interval associated with the CE failover policy case '0' and '1'. The default value is set to 300 seconds. Note that it is advisable to set the CEFTI value much higher than the CE Heartbeat Dead Interval (CE HDI) since the effect of expiring this parameter is devastating to the operation of the FE.7.3.1.1.2.13. FERestartPolicy FE restart policy - This specifies the behavior of the FE during an FE restart. The restart may be from an FE failure or other reasons that have made the FE down and then need to restart. The values are defined as follows: o 0(default)- Restart the FE from scratch. In this case, the FE should start from the pre-association phase. o Others - Reserved for future use.7.3.2. FE Object LFB
The FE Object LFB is a logical entity in each FE and contains components relative to the FE itself, and not to the operation of the ForCES protocol. The formal definition of the FE Object LFB can be found in [RFC5812]. The model captures the high-level properties of the FE that the CE needs to know to begin working with the FE. The class ID for this LFB class is also assigned in [RFC5812]. The singular instance of this class will always exist, and will always have instance ID 0x1 within its class. It is common, although not mandatory, for a CE to fetch much of the component and capability information from this LFB instance when the CE begins controlling the operation of the FE.7.4. Semantics of Message Direction
Recall: The PL provides a master(CE)-slave(FE) relationship. The LFBs reside at the FE and are controlled by CE. When messages go from the CE, the LFB selector (class and instance) refers to the destination LFB selection that resides in the FE. When messages go from the FE to the CE, the LFB selector (class and instance) refers to the source LFB selection that resides in the FE.
7.5. Association Messages
The ForCES Association messages are used to establish and tear down associations between FEs and CEs.7.5.1. Association Setup Message
This message is sent by the FE to the CE to set up a ForCES association between them. Message transfer direction: FE to CE Message header: The Message Type in the header is set to MessageType= 'AssociationSetup'. The ACK flag in the header MUST be ignored, and the Association Setup message always expects to get a response from the message receiver (CE), whether or not the setup is successful. The correlator field in the header is set, so that FE can correlate the response coming back from the CE correctly. The FE may set the source ID to 0 in the header to request that the CE should assign an FE ID for the FE in the Setup Response message. Message body: The Association Setup message body optionally consists of zero, one, or two LFBselect TLVs, as described in Section 7.1.5. The Association Setup message only operates on the FE Object and FE Protocol LFBs; therefore, the LFB class ID in the LFBselect TLV only points to these two kinds of LFBs. The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' operation. More than one component may be announced in this message using the REPORT operation to let the FE declare its configuration parameters in an unsolicited manner. These may contain components suggesting values such as the FE HB Interval or the FEID. The OPER-TLV used is defined below.
OPER-TLV for Association Setup: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for REPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: OPER-TLV Type: Only one operation type is defined for the Association Setup message: Type = "REPORT" - This type of operation is for the FE to report something to the CE. PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA BNF definition. The PATH-DATA-TLV for the REPORT operation MAY contain FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data format. The RESULT-TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in Section 7.1.8.
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = Association Setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = LFBselect | +-- LFBCLASSID = FE Protocol object | | +-- LFBInstance = 0x1 | +---OPER-TLV = REPORT | +-- Path-data to one or more components Figure 24: PDU Format for Association Setup Message7.5.2. Association Setup Response Message
This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether or not the setup is successful, i.e., whether an association is established. Message transfer direction: CE to FE Message header: The Message Type in the header is set to MessageType= 'AssociationSetupResponse'. The ACK flag in the header MUST be ignored, and the Setup Response message never expects to get any more responses from the message receiver (FE). The destination ID in the header will be set to the source ID in the corresponding Association Setup message, unless that source ID was 0. If the corresponding source ID was 0, then the CE will assign an FE ID value and use that value for the destination ID.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = ASRresult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Setup Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: ASResult OPER-TLV Type (16 bits): The type of the TLV is "ASResult". Length (16 bits): Length of the TLV including the T and L fields, in octets. Association Setup result (32 bits): This indicates whether the Setup message was successful or whether the FE request was rejected by the CE. The defined values are: 0 = success 1 = FE ID invalid 2 = permission denied
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = Association Setup Response) | | +--- T = ASResult-TLV Figure 26: PDU Format for Association Setup Response Message7.5.3. Association Teardown Message
This message can be sent by the FE or CE to any ForCES element to end its ForCES association with that element. Message transfer direction: CE to FE, or FE to CE (or CE to CE) Message Header: The Message Type in the header is set to MessageType= "AssociationTeardown". The ACK flag MUST be ignored. The correlator field in the header MUST be set to zero and MUST be ignored by the receiver. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = ASTreason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: ASTreason-TLV Type (16 bits): The type of the TLV is "ASTreason". Length (16 bits): Length of the TLV including the T and L fields, in octets. Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows.
0 - normal teardown by administrator
1 - error - loss of heartbeats
2 - error - out of bandwidth
3 - error - out of memory
4 - error - application crash
255 - error - other or unspecified
To better illustrate the above PDU format, a tree structure for the
format is shown below:
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason-TLV
Figure 28: PDU Format for Association Teardown Message
7.6. Configuration Messages
The ForCES Configuration messages are used by CE to configure the FEs
in a ForCES NE and report the results back to the CE.
7.6.1. Config Message
This message is sent by the CE to the FE to configure LFB components
in the FE. This message is also used by the CE to subscribe/
unsubscribe to LFB events.
As usual, a Config message is composed of a common header followed by
a message body that consists of one or more TLV data formats.
Detailed description of the message is as follows:
Message transfer direction:
CE to FE
Message header:
The Message Type in the header is set to MessageType= 'Config'. The
ACK flag in the header can be set to any value defined in
Section 6.1, to indicate whether or not a response from the FE is
expected by the message.
OPER-TLV for Config: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: OPER-TLV for Config Type: The operation type for Config message. Two types of operations for the Config message are defined: Type = "SET" - This operation is to set LFB components Type = "SET-PROP" - This operation is to set LFB component properties. Type = "DEL" - This operation is to delete some LFB components. Type = "COMMIT" - This operation is sent to the FE to commit in a 2pc transaction. A COMMIT TLV is an empty TLV, i.e., it has no "V"alue. In other words, there is a length of 4 (which is for the header only). Type = "TRCOMP" - This operation is sent to the FE to mark the success from an NE perspective of a 2pc transaction. A TRCOMP TLV is an empty TLV, i.e., it has no "V"alue. In other words, there is a length of 4 (which is for the header only). PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for SET/SET-PROP operation is that it MUST contain either FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on the use of PATH-DATA-TLV for DEL operation is it MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.7 and FULLDATA-TLVs and SPARSEDATA-TLVs are defined in Section 7.1.8.
Note: For Event subscription, the events will be defined by the
individual LFBs.
To better illustrate the above PDU format, a tree structure for the
format is shown below:
main hdr (type = Config)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET }
| |
| +-- // one or more path targets
| // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
|
+-- T = operation { DEL }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
.
.
Figure 30: PDU Format for Configuration Message
7.6.2. Config Response Message
This message is sent by the FE to the CE in response to the Config
message. It indicates whether or not the Config was successful on
the FE and also gives a detailed response regarding the configuration
result of each component.
Message transfer direction:
FE to CE
Message header: The Message Type in the header is set to MessageType= 'Config Response'. The ACK flag in the header is always ignored, and the Config Response message never expects to get any further response from the message receiver (CE). OPER-TLV for Config Response: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 31: OPER-TLV for Config Response Type: The operation type for Config Response message. Two types of operations for the Config Response message are defined: Type = "SET-RESPONSE" - This operation is for the response of the SET operation of LFB components. Type = "SET-PROP-RESPONSE" - This operation is for the response of the SET-PROP operation of LFB component properties. Type = "DEL-RESPONSE" - This operation is for the response of the DELETE operation of LFB components. Type = "COMMIT-RESPONSE" - This operation is sent to the CE to confirm a commit success in a 2pc transaction. A COMMIT-RESPONSE TLV MUST contain a RESULT-TLV indicating success or failure. PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for SET-RESPONSE operation is that it MUST contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV is defined in Section 7.1.7.
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = ConfigResponse) | | +--- T = LFBselect . | . +-- LFBCLASSID = target LFB class . | | +-- LFBInstance = target LFB instance | | +-- T = operation { SET-RESPONSE } | | | +-- // one or more path targets | // associated with FULL or SPARSEDATA-TLV(s) | +-- T = operation { DEL-RESPONSE } | | | +-- // one or more path targets | +-- T = operation { COMMIT-RESPONSE } | | | +-- RESULT-TLV Figure 32: PDU Format for Config Response Message7.7. Query Messages
The ForCES Query messages are used by the CE to query LFBs in the FE for information like LFB components, capabilities, statistics, etc. Query messages include the Query message and the Query Response message.7.7.1. Query Message
A Query message is composed of a common header and a message body that consists of one or more TLV data formats. Detailed description of the message is as follows: Message transfer direction: from CE to FE
Message header: The Message Type in the header is set to MessageType= 'Query'. The ACK flag in the header is always ignored, and a full response for a Query message is always expected. The Correlator field in the header is set, so that the CE can locate the response back from FE correctly. OPER-TLV for Query: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = GET/GET-PROP | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for GET/GET-PROP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 33: TLV for Query Type: The operation type for query. Two operation types are defined: Type = "GET" - This operation is to request to get LFB components. Type = "GET-PROP" - This operation is to request to get LFB component properties. PATH-DATA-TLV for GET/GET-PROP: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The restriction on the use of PATH-DATA-TLV for GET/GET-PROP operation is it MUST NOT contain any SPARSEDATA-TLV or FULLDATA- TLV and RESULT-TLV in the data format.
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = Query) | | +--- T = LFBselect . | . +-- LFBCLASSID = target LFB class . | | +-- LFBInstance = target LFB instance | | +-- T = operation { GET } | | | +-- // one or more path targets | +-- T = operation { GET } . | . +-- // one or more path targets . Figure 34: PDU Format for Query Message7.7.2. Query 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. A Query Response message is also composed of a common header and a message body consisting of one or more TLVs describing the query result. Detailed description of the message is as follows: Message transfer direction: from FE to CE Message header: The Message Type in the header is set to MessageType= 'QueryResponse'. The ACK flag in the header is ignored. As a response itself, the message does not expect a further response.
OPER-TLV for Query Response: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 35: TLV for Query Response Type: The operation type for query response. One operation type is defined: Type = "GET-RESPONSE" - This operation is for the response of the GET operation of LFB components. Type = "GET-PROP-RESPONSE" - This operation is for the response of the GET-PROP operation of LFB components. PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV for the GET-RESPONSE operation MAY contain SPARSEDATA-TLV, FULLDATA-TLV, and/or RESULT-TLV(s) in the data encoding. The RESULT-TLV is defined in Section 7.1.7 and the SPARSEDATA-TLVs and FULLDATA-TLVs are defined in Section 7.1.8.
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = QueryResponse) | | +--- T = LFBselect . | . +-- LFBCLASSID = target LFB class . | | +-- LFBInstance = target LFB instance | | +-- T = operation { GET-RESPONSE } | | | +-- // one or more path targets | +-- T = operation { GET-PROP-RESPONSE } . | . +-- // one or more path targets . Figure 36: PDU Format for Query Response Message7.8. Event Notification Message
Event Notification message is used by the FE to asynchronously notify the CE of events that happen in the FE. All events that can be generated in an FE are subscribable by the CE. The CE can subscribe to an event via a Config message with the SET- PROP operation, where the included path specifies the event, as defined by the LFB Library and described by the FE Model. As usual, an Event Notification message is composed of a common header and a message body that consists of one or more TLV data formats. Detailed description of the message is as follows: Message transfer direction: FE to CE
Message header: The Message Type in the message header is set to MessageType = 'EventNotification'. The ACK flag in the header MUST be ignored by the CE, and the Event Notification message does not expect any response from the receiver. OPER-TLV for Event Notification: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for REPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 37: TLV for Event Notification Type: Only one operation type is defined for the Event Notification message: Type = "REPORT" - This type of operation is for the FE to report something to the CE. PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in Section 7 in the PATH-DATA-TLV BNF definition. The PATH-DATA- TLV for the REPORT operation MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s) but MUST NOT contain any RESULT-TLV in the data format.
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = Event Notification) | | +--- T = LFBselect | +-- LFBCLASSID = target LFB class | | +-- LFBInstance = target LFB instance | | +-- T = operation { REPORT } | | | +-- // one or more path targets | // associated with FULL/SPARSE DATA TLV(s) +-- T = operation { REPORT } . | . +-- // one or more path targets . // associated with FULL/SPARSE DATA TLV(s) Figure 38: PDU Format for Event Notification Message7.9. Packet Redirect Message
A Packet Redirect message is used to transfer data packets between the CE and FE. Usually, these data packets are control packets, but they may be just data path packets that need further (exception or high-touch) processing. It is also feasible that this message carries no data packets and rather just meta data. The Packet Redirect message data format is formatted as follows: Message transfer direction: CE to FE or FE to CE Message header: The Message Type in the header is set to MessageType= 'PacketRedirect'.
Message body: This consists of one or more TLVs that contain or describe the packet being redirected. The TLV is specifically a Redirect TLV (with the TLV Type="Redirect"). Detailed data format of a Redirect TLV for a Packet Redirect message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Redirect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirect Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 39: Redirect_Data TLV Meta Data TLV: This is a TLV that specifies meta data associated with followed redirected data. The TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = METADATA-TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 40: METADATA-TLV
Meta Data ILV: This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 41: Meta Data ILV where Meta Data ID is an identifier for the meta data, which is statically assigned by the LFB definition. Redirect Data TLV: This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REDIRECTDATA-TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirected Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 42: Redirect Data TLV Redirected Data: This field contains the packet that is to be redirected in network byte order. The packet should be 32 bits aligned as is the data for all TLVs. The meta data infers what kind of packet is carried in value field and therefore allows for easy decoding of data encapsulated.
To better illustrate the above PDU format, a tree structure for the format is shown below: main hdr (type = PacketRedirect) | | +--- T = Redirect . | . +-- T = METADATA-TLV | | | +-- Meta Data ILV | | | +-- Meta Data ILV | . | . | +-- T = REDIRECTDATA-TLV | +-- // Redirected Data Figure 43: PDU Format for Packet Redirect Message7.10. Heartbeat Message
The Heartbeat (HB) message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. Section 4.3.3 describes the traffic- sensitive approach used. A Heartbeat message is sent by a ForCES element periodically. The parameterization and policy definition for heartbeats for an FE are managed as components of the FE Protocol Object LFB, and can be set by CE via a Config message. The Heartbeat message is a little different from other protocol messages in that it is only composed of a common header, with the message body left empty. A detailed description of the message is as follows: Message transfer direction: FE to CE or CE to FE Message header: The Message Type in the message header is set to MessageType = 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. The ACK flag in the header MUST be set to either 'NoACK' or 'AlwaysACK' when the HB is sent.
* When set to 'NoACK', the HB is not soliciting for a response.
* When set to 'AlwaysACK', the HB Message sender is always
expecting a response from its receiver. According to the HB
policies defined in Section 7.3.1, only the CE can send such
an HB message to query FE liveness. For simplicity and
because of the minimal nature of the HB message, the response
to an HB message is another HB message, i.e., no specific HB
Response message is defined. Whenever an FE receives an HB
message marked with 'AlwaysACK' from the CE, the FE MUST send
an HB message back immediately. The HB message sent by the
FE in response to the 'AlwaysACK' MUST modify the source and
destination IDs so that the ID of the FE is the source ID and
the CE ID of the sender is the destination ID, and MUST
change the ACK information to 'NoACK'. A CE MUST NOT respond
to an HB message with 'AlwaysACK' set.
* When set to anything else other than 'NoACK' or 'AlwaysACK',
the HB message is treated as if it was a 'NoACK'.
The correlator field in the HB message header SHOULD be set
accordingly when a response is expected so that a receiver can
correlate the response correctly. The correlator field MAY be
ignored if no response is expected.
Message body:
The message body is empty for the Heartbeat message.
8. High Availability Support
The ForCES protocol provides mechanisms for CE redundancy and
failover, in order to support High Availability as defined in
[RFC3654]. FE redundancy and FE to FE interaction is currently out
of scope of this document. There can be multiple redundant CEs and
FEs in a ForCES NE. However, at any one time only one primary CE can
control the FEs though there can be multiple secondary CEs. The FE
and the CE PL are aware of the primary and secondary CEs. This
information (primary, secondary CEs) is configured in the FE and in
the CE PLs during pre-association by the FEM and the CEM
respectively. Only the primary CE sends control messages to the FEs.
8.1. Relation with the FE Protocol
High Availability parameterization in an FE is driven by configuring
the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1).
The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
Heartbeat policy help in detecting connectivity problems between an FE and CE. The CE failover policy defines the reaction on a detected failure. Figure 44 extends the state machine illustrated in Figure 4 to allow for new states that facilitate connection recovery. (CE issues Teardown || +-----------------+ Lost association) && | Pre-association | CE failover policy = 0 | (Association | +------------>-->-->| in +<----+ | | progress) | | | CE issues +--------+--------+ | | Association | | CFTI | Setup V | timer | ___________________+ | expires | | | | V ^ +-+-----------+ +-------+-----+ | | | Not | | | (CE issues Teardown || | Associated | | | Lost association) && | | | Associated | CE failover policy = 1 | (May | | | | Continue | | |---------->------->------>| Forwarding)| | | | | +-------------+ +-------------+ ^ V | | | CE issues | | Association | | Setup | +_________________________________________+ Figure 44: FE State Machine Considering HA Section 4.2 describes transitions between the pre-association, associated, and not associated states. When communication fails between the FE and CE (which can be caused by either the CE or link failure but not FE related), either the TML on the FE will trigger the FE PL regarding this failure or it will be detected using the HB messages between FEs and CEs. The communication failure, regardless of how it is detected, MUST be considered as a loss of association between the CE and corresponding FE.
If the FE's FEPO CE failover policy is configured to mode 0 (the default), it will immediately transition to the pre-association phase. This means that if association is again established, all FE state will need to be re-established. If the FE's FEPO CE failover policy is configured to mode 1, it indicates that the FE is capable of HA restart recovery. In such a case, the FE transitions to the not associated state and the CEFTI timer is started. The FE MAY continue to forward packets during this state. It MAY also recycle through any configured secondary CEs in a round-robin fashion. It first adds its primary CE to the tail of backup CEs and sets its primary CE to be the first secondary. It then attempts to associate with the CE designated as the new primary CE. If it fails to re-associate with any CE and the CEFTI expires, the FE then transitions to the pre-association state. If the FE, while in the not associated state, manages to reconnect to a new primary CE before CEFTI expires, it transitions to the associated state. Once re-associated, the FE tries to recover any state that may have been lost during the not associated state. How the FE achieves this is out of scope for this document. Figure 45 below illustrates the ForCES message sequences that the FE uses to recover the connection. FE CE Primary CE Secondary | | | | Asso Estb,Caps exchg | | 1 |<--------------------->| | | | | | All msgs | | 2 |<--------------------->| | | | | | | | | FAILURE | | | | Asso Estb,Caps exchange | 3 |<------------------------------------------>| | | | Event Report (pri CE down) | 4 |------------------------------------------->| | | | All Msgs | 5 |<------------------------------------------>| Figure 45: CE Failover for Report Primary Mode
A CE-to-CE synchronization protocol would be needed to support fast failover as well as to address some of the corner cases; however, this will not be defined by the ForCES protocol as it is out of scope for this specification. An explicit message (a Config message setting primary CE component in the FE Protocol Object) from the primary CE can also be used to change the primary CE for an FE during normal protocol operation. Also note that the FEs in a ForCES NE could also use a multicast CE ID, i.e., they could be associated with a group of CEs (this assumes the use of a CE-CE synchronization protocol, which is out of scope for this specification). In this case, the loss of association would mean that communication with the entire multicast group of CEs has been lost. The mechanisms described above will apply for this case as well during the loss of association. If, however, the secondary CE was also using the multicast CE ID that was lost, then the FE will need to form a new association using a different CE ID. If the capability exists, the FE MAY first attempt to form a new association with the original primary CE using a different non-multicast CE ID.8.2. Responsibilities for HA
TML level: 1. The TML controls logical connection availability and failover. 2. The TML also controls peer HA management. At this level, control of all lower layers, for example, transport level (such as IP addresses, MAC addresses, etc.) and associated links going down are the role of the TML. PL level: All other functionality, including configuring the HA behavior during setup, the CE IDs used to identify primary and secondary CEs, protocol messages used to report CE failure (Event Report), Heartbeat messages used to detect association failure, messages to change the primary CE (Config), and other HA-related operations described before, are the PL responsibility. 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 available. If the CE is totally unreachable, then the PL would be informed and it would take the appropriate actions described earlier.
(next page on part 5)
