draft-ietf-forces-applicability-00.txt   draft-ietf-forces-applicability-01.txt 
Internet Engineering Task Force ForCES WG Internet Engineering Task Force ForCES WG
INTERNET-DRAFT Alan Crouch/Intel Labs INTERNET-DRAFT Alan Crouch/Intel
draft-ietf-forces-applicability-00.txt Mark Handley/ACIRI draft-ietf-forces-applicability-01.txt Mark Handley/ICIR
19 June 2002
Expires: December 2002 14 December 2002
Expires: June 2003
ForCES Applicability Statement ForCES Applicability Statement
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 2, line 9 skipping to change at page 2, line 19
Forwarding Engines in IP routers and similar devices. In this Forwarding Engines in IP routers and similar devices. In this
document we describe the applicability of the ForCES model and document we describe the applicability of the ForCES model and
protocol. We provide example deployment scenarios and protocol. We provide example deployment scenarios and
functionality, as well as document applications that would be functionality, as well as document applications that would be
inappropriate for ForCES. inappropriate for ForCES.
1. Purpose 1. Purpose
The purpose of the ForCES Applicability Statement is to capture the The purpose of the ForCES Applicability Statement is to capture the
intent of the ForCES protocol designers as to how the protocol should be intent of the ForCES protocol designers as to how the protocol should be
used. This Applicability Statement will evolve alongside the protocol, used. The Applicability Statement will evolve alongside the protocol,
with the intent that it be published as an informational RFC around the and will go to RFC as informational around the same time the as the
same time that the ForCES protocol is published as a standards-track protocol goes to RFC.
RFC.
2. Overview 2. Overview
The ForCES protocol defines a standard framework and mechanism for the The ForCES protocol defines a standard framework and mechanism for the
exchange of information between the logically separate functionality of exchange of information between the logically separate functionality of
the control and data forwarding planes of IP routers and similar the control and data forwarding planes of IP routers and similar
devices. It focuses on the communication necessary for separation of devices. It focuses on the communication necessary for separation of
control plane functionality such as routing protocols, signaling control plane functionality such as routing protocols, signaling
protocols, and admission control from data forwarding plane per-packet protocols, and admission control from data forwarding plane per-packet
activities such as packet forwarding, queuing, and header editing. activities such as packet forwarding, queuing, and header editing.
skipping to change at page 7, line 37 skipping to change at page 8, line 7
5.1.2. Separation of Control and Forwarding in Multimedia Gateways" 5.1.2. Separation of Control and Forwarding in Multimedia Gateways"
MEGACO defines a protocol used between elements of a physically MEGACO defines a protocol used between elements of a physically
decomposed multimedia gateway. Separation of call control channels from decomposed multimedia gateway. Separation of call control channels from
bearer channels is the purview of MEGACO. For more information on bearer channels is the purview of MEGACO. For more information on
MEGACO, see [7]. MEGACO, see [7].
5.2. Localities 5.2. Localities
The ForCES protocol was intended to work within the localities described ForCES protocol was intended to work within the localities described in
in section 4.3. While the ForCES protocol might be able to work in a the last section. Outside these boundaries, care must be taken or the
wider range of circumstances, anyone trying to do so should be aware protocol may not work right. Examples of localities where ForCES was
that it has not been designed or evaluated for such use. In particular, not originally intended to be used:
there are many clear cases where arbitrary separation of control and
forwarding would render network operation significantly more fragile
than non-separated forwarding.
Examples of localities where ForCES was not designed or evaluated for
use are:
o Localities where there are multiple hops between CE and FE. o Localities where there are multiple hops between CE and FE.
o Localities where hops between the CE and FE are dynamically routing o Localities where hops between the CE and FE are dynamically routing
using IP routing protocols. using IP routing protocols.
o Localities where the loss of the CE-FE link is of non-negligible o Localities where the loss of the CE-FE link is of non-negligible
probability. probability.
o Localities where two or more FEs controlled by the same CE cannot o Localities where two or more FEs controlled by the same CE cannot
skipping to change at page 8, line 30 skipping to change at page 8, line 39
[1]. The ForCES protocol assumes that the CE and FE are in the same [1]. The ForCES protocol assumes that the CE and FE are in the same
administration, and have shared secrets as a means of administration. administration, and have shared secrets as a means of administration.
Whilst it might be technically feasible to have the CE and FE Whilst it might be technically feasible to have the CE and FE
administered independently, we strongly discourage such uses, because administered independently, we strongly discourage such uses, because
they would require a significantly different trust model from that they would require a significantly different trust model from that
ForCES assumes. ForCES assumes.
7. Normative 7. Normative
[1] Anderson, T et. al., "Requirements for Separation of IP Control and [1] Anderson, T et. al., "Requirements for Separation of IP Control and
Forwarding", draft-ietf-forces-requirements-01.txt, Intel Labs, Forwarding", draft-ietf-forces-requirements-07.txt, October 2002
September 2001.
[2] ForCES Protocol Specification (to-be-written) [2] ForCES Protocol Specification (to-be-written)
8. Informative 8. Informative
[3] Salim, J e. al., "Netlink as an IP Services Protocol", draft-salim- [3] Salim, J e. al., "Netlink as an IP Services Protocol", draft-ietf-
netlink-jhsk-01.txt, Znyx Networks, September 2001. forces-netlink-03.txt, June 2002
[4] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General switch [4] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General Switch
Management Protocol V3," Internet Draft draft-ietf-gsmp-06.txt, July Management Protocol (GSMP) V3" RFC 3292, June 2002
2000. work in progress
[5] Andersson et al., "LDP Specification" RFC 3036, January 2001 [5] Andersson et al., "LDP Specification" RFC 3036, January 2001
[6] Bradner, S, "Key words for use in RFCs to Indicate Requirement [6] Bradner, S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997. Levels", RFC 2119, Harvard University, March 1997
[7] F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November [7] F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November
2000 2000
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Jamal Hadi, Hormuzd Khosravi, Vip Sharma, and The authors wish to thank Jamal Hadi, Hormuzd Khosravi, Vip Sharma, and
many others for their invaluable contributions. many others for their invaluable contributions.
10. Author's Addresses 10. Author's Addresses
Alan Crouch Alan Crouch
skipping to change at page 9, line 15 skipping to change at page 9, line 21
2000 2000
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Jamal Hadi, Hormuzd Khosravi, Vip Sharma, and The authors wish to thank Jamal Hadi, Hormuzd Khosravi, Vip Sharma, and
many others for their invaluable contributions. many others for their invaluable contributions.
10. Author's Addresses 10. Author's Addresses
Alan Crouch Alan Crouch
Intel Labs Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 264 2196 Phone: +1 503 264 2196
Email: alan.crouch@intel.com Email: alan.crouch@intel.com
Mark Handley Mark Handley
ICSI ICIR
1947 Center Street, Suite 600 1947 Center Street, Suite 600
Berkeley, CA 94704, USA Berkeley, CA 94708, USA
Email: mjh@icsi.berkeley.edu Email: mjh@icsi.berkeley.edu
 End of changes. 

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