draft-ietf-forces-protocol-18.txt   draft-ietf-forces-protocol-19.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: May 3, 2009 IBM Expires: May 21, 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
October 30, 2008 November 17, 2008
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-18.txt draft-ietf-forces-protocol-19.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 May 3, 2009. This Internet-Draft will expire on May 21, 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 4, line 43 skipping to change at page 4, line 43
7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 73 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 73
7.7.2. Query Response Message . . . . . . . . . . . . . . . 75 7.7.2. Query Response Message . . . . . . . . . . . . . . . 75
7.8. Event Notification Message . . . . . . . . . . . . . . . 77 7.8. Event Notification Message . . . . . . . . . . . . . . . 77
7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 79 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 79
7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82
8. High Availability Support . . . . . . . . . . . . . . . . . . 84 8. High Availability Support . . . . . . . . . . . . . . . . . . 84
8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84
8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87
9. Security Considerations . . . . . . . . . . . . . . . . . . . 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 88 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 88
9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 88 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 89
9.1.2. Message Authentication . . . . . . . . . . . . . . . 89 9.1.2. Message Authentication . . . . . . . . . . . . . . . 89
9.2. ForCES PL and TML security service . . . . . . . . . . . 89 9.2. ForCES PL and TML security service . . . . . . . . . . . 89
9.2.1. Endpoint authentication service . . . . . . . . . . . 89 9.2.1. Endpoint authentication service . . . . . . . . . . . 89
9.2.2. Message authentication service . . . . . . . . . . . 89 9.2.2. Message authentication service . . . . . . . . . . . 90
9.2.3. Confidentiality service . . . . . . . . . . . . . . . 89 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 90
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.1. Normative References . . . . . . . . . . . . . . . . . . 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 92
11.2. Informational References . . . . . . . . . . . . . . . . 91 11.2. Informational References . . . . . . . . . . . . . . . . 92
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 93
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 93
A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 93 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 94
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 94 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 95
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 94 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 95
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 94 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 95
A.6. Association Setup Response . . . . . . . . . . . . . . . 95 A.6. Association Setup Response . . . . . . . . . . . . . . . 96
A.7. Association Teardown Message . . . . . . . . . . . . . . 96 A.7. Association Teardown Message . . . . . . . . . . . . . . 97
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 97 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 98
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 102 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 103
B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 102 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 103
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 103 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 104
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 107 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 108
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123
Intellectual Property and Copyright Statements . . . . . . . . . 124 Intellectual Property and Copyright Statements . . . . . . . . . 125
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Other Notation 1.2. Other Notation
skipping to change at page 27, line 19 skipping to change at page 27, line 19
to Section 6.1 and for the semantics of the protocol refer to to Section 6.1 and for the semantics of the protocol refer to
Section 4.3. Section 4.3.
4.4.1. Association Setup State 4.4.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
associations have to be established between them before any associations have to be established between them before any
association messages can be exchanged. The TML will take care of association messages can be exchanged. The TML MUST take care of
establishing any security associations. establishing any security associations.
This is typically followed by capability query, topology query, etc. This is typically followed by capability query, topology query, etc.
When the FE is ready to start processing the data path, it sets the When the FE is ready to start processing the data path, it sets the
FEO FEState component to OperEnable (Refer to [FE-MODEL] for details) FEO FEState component to OperEnable (Refer to [FE-MODEL] for details)
and reports it to the CE as such when it is first queried. Typically and reports it to the CE as such when it is first queried. Typically
the FE is expected to be ready to process the data path before it the FE is expected to be ready to process the data path before it
associates, but there maybe rare cases where it needs time do some associates, but there maybe rare cases where it needs time do some
pre-processing - in such a case the FE will start in the OperDisable pre-processing - in such a case the FE will start in the OperDisable
state and when it is ready will transition to OperEnable state. An state and when it is ready will transition to OperEnable state. An
skipping to change at page 31, line 22 skipping to change at page 31, line 22
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. A TML layer TML provides security services to the ForCES PL. A TML layer
should support the following security services and describe how SHOULD support the following security services and describe how
they are achieved. they are achieved.
* Endpoint authentication of FE and CE * Endpoint authentication of FE and CE
* Message authentication * Message authentication
* Confidentiality service * Confidentiality service
The TML SHOULD provide these services by employing TLS or IPSEC.
3. Congestion control 3. Congestion control
The congestion control scheme used needs to be defined. The The congestion control scheme used needs to be defined. The
congestion control mechanism defined by the TML should prevent congestion control mechanism defined by the TML should prevent
the FE from being overloaded by the CE or the CE from being the FE from being overloaded by the CE or the CE from being
overwhelmed by traffic from the FE. Additionally, the overwhelmed by traffic from the FE. Additionally, the
circumstances under which notification is sent to the PL to circumstances under which notification is sent to the PL to
notify it of congestion must be defined. notify it of congestion must be defined.
4. Uni/multi/broadcast addressing/delivery, if any 4. Uni/multi/broadcast addressing/delivery, if any
If there is any mapping between PL and TML level uni/multi/ If there is any mapping between PL and TML level uni/multi/
skipping to change at page 73, line 34 skipping to change at page 73, line 34
| |
+-- T = operation { COMMIT-RESPONSE } +-- T = operation { COMMIT-RESPONSE }
| | | |
| +-- RESULT-TLV | +-- RESULT-TLV
Figure 31: PDU Format for Configuration Response message Figure 31: PDU Format for Configuration Response message
7.7. Query Messages 7.7. Query Messages
The ForCES query messages are used by the CE to query LFBs in the FE The ForCES query messages are used by the CE to query LFBs in the FE
for informations like LFB components, capabilities, statistics, etc. for information like LFB components, capabilities, statistics, etc.
Query Messages include the Query Message and the Query Response Query Messages include the Query Message and the Query Response
Message. Message.
7.7.1. Query Message 7.7.1. Query Message
A Query message is composed of a common header and a message body A Query message is composed of a common header and a message body
that consists of one or more TLV data format. Detailed description that consists of one or more TLV data format. Detailed description
of the message is as below. of the message is as below.
Message transfer direction: Message transfer direction:
skipping to change at page 79, line 35 skipping to change at page 79, line 35
Figure 37: PDU Format for Event Notification Message Figure 37: PDU Format for Event Notification Message
7.9. Packet Redirect Message 7.9. Packet Redirect Message
A packet Redirect message is used to transfer data packets between CE A packet Redirect message is used to transfer data packets between CE
and FE. Usually these data packets are control packets but they may and FE. Usually these data packets are control packets but they may
be just data-path packets which need further (exception or high- be just data-path packets which need further (exception or high-
touch) processing. It is also feasible that this message carries no touch) processing. It is also feasible that this message carries no
data packets and rather just metadata. data packets and rather just metadata.
The Packet Redirect message data format is formated as follows: The Packet Redirect message data format is formatted as follows:
Message Direction: Message Direction:
CE to FE or FE to CE CE to FE or FE to CE
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set to MessageType=
'PacketRedirect'. 'PacketRedirect'.
Message Body: Message Body:
This consists of one or more TLVs that contain or describe the This consists of one or more TLVs that contain or describe the
skipping to change at page 88, line 7 skipping to change at page 88, line 7
primary CE (Config), and other HA related operations described primary CE (Config), and other HA related operations described
before, are the PL responsibility. before, are the PL responsibility.
To put the two together, if a path to a primary CE is down, the TML To put the two together, if a path to a primary CE is down, the TML
would take care of failing over to a backup path, if one is would take care of failing over to a backup path, if one is
available. If the CE is totally unreachable then the PL would be available. If the CE is totally unreachable then the PL would be
informed and it would take the appropriate actions described before. informed and it would take the appropriate actions described before.
9. Security Considerations 9. Security Considerations
ForCES Framework document [RFC3746], section 8 goes into a lot of ForCES Framework document [RFC3746], section 8 goes into extensive
details and identifies several levels of security challenges. This detail on a variety of security threats, the possible effects of
those threats on the protocol and responses to those threats. This
document does not repeat that discussion, the reader is referred to document does not repeat that discussion, the reader is referred to
the ForCES Framework document[RFC3746] for those details and how the ForCES Framework document [RFC3746] for those details and how the
the ForCES architecture addresses them. ForCES architecture addresses them.
ForCES PL uses security services provided by the ForCES TML. The TML ForCES PL uses security services provided by the ForCES TML. The TML
provides security services such as endpoint authentication service, provides security services such as endpoint authentication service,
message authentication service and confidentiality service. Endpoint message authentication service and confidentiality service. Endpoint
authentication service is invoked at the time of the pre-association authentication service is invoked at the time of the pre-association
connection establishment phase and message authentication is connection establishment phase and message authentication is
performed whenever the FE or CE receives a packet from its peer. performed whenever the FE or CE receives a packet from its peer.
The following are the general security mechanisms that need to be in The following are the general security mechanisms that need to be in
place for ForCES PL. place for ForCES PL.
skipping to change at page 88, line 46 skipping to change at page 88, line 47
endpoint authentication and message authentication service needs to endpoint authentication and message authentication service needs to
be performed by ForCES PL. Both these mechanism are weak and do not be performed by ForCES PL. Both these mechanism are weak and do not
involve cryptographic operation. An operator can choose "No involve cryptographic operation. An operator can choose "No
Security" level when the ForCES protocol endpoints are within a Security" level when the ForCES protocol endpoints are within a
single box, for example. single box, for example.
In order to have interoperable and uniform implementation across In order to have interoperable and uniform implementation across
various security levels, each CE and FE endpoint MUST implement this various security levels, each CE and FE endpoint MUST implement this
level. level.
What is described below (in Section 9.1.1 and Section 9.1.2) are
error checks and not security procedures. The reader is referred to
section Section 9.2. for security procedures.
9.1.1. Endpoint Authentication 9.1.1. Endpoint Authentication
Each CE and FE PL maintains a list of associations as part its of Each CE and FE PL maintains a list of associations as part its of
configuration. This is done via the CEM and FEM interfaces. An FE configuration. This is done via the CEM and FEM interfaces. An FE
MUST connect to only those CEs that are configured via the FEM; MUST connect to only those CEs that are configured via the FEM;
similarly, a CE should accept the connection and establish similarly, a CE should accept the connection and establish
associations for the FEs which are configured via the CEM. The CE associations for the FEs which are configured via the CEM. The CE
should validate the FE identifier before accepting the connections should validate the FE identifier before accepting the connections
during the pre-association phase. during the pre-association phase.
skipping to change at page 89, line 35 skipping to change at page 89, line 43
protocol and the nature of the connection. protocol and the nature of the connection.
All these configurations should be done prior to starting the CE and All these configurations should be done prior to starting the CE and
FE. FE.
When certificates-based authentication is being used at the TML, the When certificates-based authentication is being used at the TML, the
certificate can use a ForCES-specific naming structure as certificate certificate can use a ForCES-specific naming structure as certificate
names and, accordingly, the security policies can be configured at names and, accordingly, the security policies can be configured at
the CE and FE. the CE and FE.
The reader is asked to refer to specific TML documents for details on
the security requirements specific to that TML
9.2.1. Endpoint authentication service 9.2.1. Endpoint authentication service
When TML security services are enabled, the ForCES TML performs When TML security services are enabled, the ForCES TML performs
endpoint authentication. Security association is established between endpoint authentication. Security association is established between
CE and FE and is transparent to the ForCES PL. CE and FE and is transparent to the ForCES PL.
9.2.2. Message authentication service 9.2.2. Message authentication service
This is a TML specific operation and is transparent to the ForCES PL. This is a TML specific operation and is transparent to the ForCES PL.
For details, refer to Section 5. For details, refer to Section 5.
 End of changes. 15 change blocks. 
34 lines changed or deleted 44 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/