draft-ietf-forces-protocol-16.txt   draft-ietf-forces-protocol-17.txt 
Network Working Group A. Doria (Ed.) Network Working Group A. Doria (Ed.)
Internet-Draft Lulea University of Technology Internet-Draft Lulea University of Technology
Intended status: Standards Track R. Haas (Ed.) Intended status: Standards Track R. Haas (Ed.)
Expires: March 20, 2009 IBM Expires: March 29, 2009 IBM
J. Hadi Salim (Ed.) J. Hadi Salim (Ed.)
Znyx Znyx
H. Khosravi (Ed.) H. Khosravi (Ed.)
Intel Intel
W. M. Wang (Ed.) W. M. Wang (Ed.)
Zhejiang Gongshang University Zhejiang Gongshang University
September 16, 2008 September 25, 2008
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-16.txt draft-ietf-forces-protocol-17.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 20, 2009. This Internet-Draft will expire on March 29, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies the Forwarding and Control Element Separation This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications (ForCES) protocol. ForCES protocol is used for communications
between Control Elements(CEs) and Forwarding Elements (FEs) in a between Control Elements(CEs) and Forwarding Elements (FEs) in a
skipping to change at page 3, line 24 skipping to change at page 3, line 24
Joel Halpern who has done extensive editing in support of congruence Joel Halpern who has done extensive editing in support of congruence
between the model and this protocol specification. Without his between the model and this protocol specification. Without his
participation and persistence, this specification might never have participation and persistence, this specification might never have
been completed. been completed.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 6
1.3. Integers . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11
4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 17 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 17
skipping to change at page 7, line 5 skipping to change at page 6, line 22
1.2. Other Notation 1.2. Other Notation
In Table 1 and Table 2 the following notation is used to indicate In Table 1 and Table 2 the following notation is used to indicate
multiplicity: multiplicity:
(value)+ .... means "1 or more instance of value" (value)+ .... means "1 or more instance of value"
(value)* .... means "0 or more instance of value" (value)* .... means "0 or more instance of value"
1.3. Integers
All integers are to be coded as unsigned binary integers of
appropriate length.
2. Introduction 2. Introduction
Forwarding and Control Element Separation (ForCES) defines an Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined
the ForCES requirements, and RFC 3746 has defined the ForCES the ForCES requirements, and RFC 3746 has defined the ForCES
framework. While there may be multiple protocols used within the framework. While there may be multiple protocols used within the
overall ForCES architecture, the term "ForCES protocol" and overall ForCES architecture, the term "ForCES protocol" and
"protocol" as used in this document refers to the protocol used to "protocol" as used in this document refers to the protocol used to
skipping to change at page 15, line 13 skipping to change at page 15, line 13
Example of connection association parameters this might be: Example of connection association parameters this might be:
o simple parameters: send up to 3 association messages every 1 o simple parameters: send up to 3 association messages every 1
second second
o complex parameters: send up to 4 association messages with o complex parameters: send up to 4 association messages with
increasing exponential timeout increasing exponential timeout
4.2. ForCES Protocol Phases 4.2. ForCES Protocol Phases
ForCES, in relation to NEs, involves two phases: the Pre-Association ForCES, in relation to NEs, involves two phases: the pre-association
phase, where configuration/initialization/bootup of the TML and PL phase, where configuration/initialization/bootup of the TML and PL
layer happens, and the post-association phase where the ForCES layer happens, and the post-association phase where the ForCES
protocol operates to manipulate the parameters of the FEs. protocol operates to manipulate the parameters of the FEs.
CE sends Association Setup CE sends Association Setup
+---->--->------------>---->---->---->------->----+ +---->--->------------>---->---->---->------->----+
| Y | Y
^ | ^ |
| Y | Y
+---+-------+ +-------------+ +---+-------+ +-------------+
|FE Pre- | | FE | |FE Pre- | | FE Post- |
|Association| CE sends Association Teardown | Associated | |Association| CE sends Association Teardown | Association |
|Phase |<------- <------<-----<------<-------+ | |Phase |<------- <------<-----<------<-------+ Phase |
| | | | | | | |
+-----------+ +-------------+ +-----------+ +-------------+
^ Y ^ Y
| | | |
+-<---<------<-----<------<----<---------<------+ +-<---<------<-----<------<----<---------<------+
FE loses association FE loses association
Figure 4: The FE Protocol Phases Figure 4: The FE Protocol Phases
In the mandated case, once associated, the FE may forward packets In the mandated case, once associated, the FE may forward packets
skipping to change at page 33, line 22 skipping to change at page 33, line 22
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length | |version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID | | Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[32:63] | | Correlator[63:32] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator[0:31] | | Correlator[31:0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Common Header Figure 10: Common Header
The message is 32 bit aligned. The message is 32 bit aligned.
Version (4 bit): Version (4 bit):
Version number. Current version is 1. Version number. Current version is 1.
skipping to change at page 35, line 32 skipping to change at page 35, line 32
Response message. In the case where the message from the CE does Response message. In the case where the message from the CE does
not elicit a response, this field may not be useful. not elicit a response, this field may not be useful.
The correlator field could be used in many implementations The correlator field could be used in many implementations
specific ways by the CE. For example, the CE could split the specific ways by the CE. For example, the CE could split the
correlator into a 32-bit transactional identifier and 32-bit correlator into a 32-bit transactional identifier and 32-bit
message sequence identifier. Another example is a 64-bit pointer message sequence identifier. Another example is a 64-bit pointer
to a context block. All such implementation specific use of the to a context block. All such implementation specific use of the
correlator is outside the scope of this specification. correlator is outside the scope of this specification.
It should be noted that the correlator is transmitted on the
network as if it were a 64 bit unsigned integer with the leftmost
or most significant octet (bits 63-56) transmitted first.
Whenever the correlator field is not relevant, because no message Whenever the correlator field is not relevant, because no message
is expected, the correlator field is set to 0. is expected, the correlator field is set to 0.
Flags(32 bits): Flags(32 bits):
Identified so far: Identified so far:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |
skipping to change at page 43, line 43 skipping to change at page 43, line 43
| Response | | SET-PROP-RESPONSE | | | | Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | | | | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | | | | | COMMIT-RESPONSE)+ | |
| | | | | | | | | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| | | | | | | | | |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | | | Response | | GET-PROP-RESPONSE)+ | |
| | | | | | | | | |
| Event | LFBselect | REPORT | Section 7.8 | | Event | LFBselect | REPORT | Section 7.8 |
| Notificatio | | | | | Notifi- | | | |
| n | | | | | cation | | | |
| | | | | | | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 | | Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | | | Redirect | | | |
| | | | | | | | | |
| Heartbeat | none | none | Section 7.10 | | Heartbeat | none | none | Section 7.10 |
+-------------+---------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
Table 1 Table 1
The different messages are illustrated in Table 1. The different The different messages are illustrated in Table 1. The different
message type numerical values are defined in Appendix A.1. All the message type numerical values are defined in Appendix A.1. All the
skipping to change at page 86, line 11 skipping to change at page 86, line 11
If the FE's FEPO CE Failover Policy is configured to mode 1, it If the FE's FEPO CE Failover Policy is configured to mode 1, it
indicates that the FE is capable of HA restart recovery. In such a indicates that the FE is capable of HA restart recovery. In such a
case, the FE transitions to the not associated state and the CEFTI case, the FE transitions to the not associated state and the CEFTI
timer is started. The FE MAY continue to forward packets during this timer is started. The FE MAY continue to forward packets during this
state. It MAY also recycle through any configured secondary CEs in a state. It MAY also recycle through any configured secondary CEs in a
round-robin fashion. It first adds its primary CE to the tail of round-robin fashion. It first adds its primary CE to the tail of
backup CEs and sets its primary CE to be the first secondary. It backup CEs and sets its primary CE to be the first secondary. It
then attempts to associate with the CE designated as the new primary then attempts to associate with the CE designated as the new primary
CE. If it fails to re-associate with any CE and the CEFTI expires, CE. If it fails to re-associate with any CE and the CEFTI expires,
the FE then transitions to the Pre-association state. the FE then transitions to the pre-association state.
If the FE, while in the not associated state, manages to reconnect to If the FE, while in the not associated state, manages to reconnect to
a new primary CE before CEFTI expires it transitions to the a new primary CE before CEFTI expires it transitions to the
Associated state. Once re-associated, the FE tries to recover any Associated state. Once re-associated, the FE tries to recover any
state that may have been lost during the not associated state. How state that may have been lost during the not associated state. How
the FE achieves re-synchronizes it state is out of scope for this the FE achieves re-synchronizes it state is out of scope for this
document. document.
Figure 44 below illustrates the Forces message sequences that the FE Figure 44 below illustrates the Forces message sequences that the FE
uses to recover the connection. uses to recover the connection.
 End of changes. 13 change blocks. 
13 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/