draft-ietf-forces-framework-09.txt   draft-ietf-forces-framework-10.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: March 2004 Intel Corp. Expiration: April 2004 Intel Corp.
File: draft-ietf-forces-framework-09.txt R. Dantu File: draft-ietf-forces-framework-10.txt R. Dantu
Working Group: ForCES Univ. of North Texas Working Group: ForCES Univ. of North Texas
T. Anderson T. Anderson
Intel Corp. Intel Corp.
R. Gopal R. Gopal
Nokia Nokia
September 2003 October 2003
Forwarding and Control Element Separation (ForCES) Framework Forwarding and Control Element Separation (ForCES) Framework
draft-ietf-forces-framework-09.txt draft-ietf-forces-framework-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 2, line ? skipping to change at page 2, line ?
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines the architectural framework for the ForCES This document defines the architectural framework for the ForCES
(Forwarding and Control Element Separation) network elements, and (Forwarding and Control Element Separation) network elements, and
identifies the associated entities and the interactions among them. identifies the associated entities and the interactions among them.
Table of Contents Table of Contents
1. Definitions...................................................3 1. Definitions...................................................3
1.1. Conventions used in this document........................3
1.2. Terminologies............................................3
2. Introduction to Forwarding and Control Element Separation 2. Introduction to Forwarding and Control Element Separation
(ForCES).........................................................5 (ForCES).........................................................5
3. Architecture..................................................9 3. Architecture..................................................9
3.1. Control Elements and Fr Reference Point.................10 3.1. Control Elements and Fr Reference Point.................10
3.2. Forwarding Elements and Fi reference point..............11 3.2. Forwarding Elements and Fi reference point..............11
3.3. CE Managers.............................................14 3.3. CE Managers.............................................14
3.4. FE Managers.............................................14 3.4. FE Managers.............................................15
4. Operational Phases...........................................15 4. Operational Phases...........................................15
4.1. Pre-association Phase...................................15 4.1. Pre-association Phase...................................15
4.1.1. Fl Reference Point.................................15 4.1.1. Fl Reference Point.................................15
4.1.2. Ff Reference Point.................................16 4.1.2. Ff Reference Point.................................16
4.1.3. Fc Reference Point.................................17 4.1.3. Fc Reference Point.................................17
4.2. Post-association Phase and Fp reference point...........17 4.2. Post-association Phase and Fp reference point...........17
4.2.1. Proximity and Interconnect between CEs and FEs.....17 4.2.1. Proximity and Interconnect between CEs and FEs.....17
4.2.2. Association Establishment..........................18 4.2.2. Association Establishment..........................18
4.2.3. Steady-state Communication.........................19 4.2.3. Steady-state Communication.........................19
4.2.4. Data Packets across Fp reference point.............20 4.2.4. Data Packets across Fp reference point.............20
4.2.5. Proxy FE...........................................21 4.2.5. Proxy FE...........................................21
4.3. Association Re-establishment............................21 4.3. Association Re-establishment............................21
4.3.1. CE graceful restart................................22 4.3.1. CE graceful restart................................22
4.3.2. FE restart.........................................23 4.3.2. FE restart.........................................23
5. Applicability to RFC1812.....................................24 5. Applicability to RFC1812.....................................24
5.1. General Router Requirements.............................24 5.1. General Router Requirements.............................25
5.2. Link Layer..............................................26 5.2. Link Layer..............................................26
5.3. Internet Layer Protocols................................26 5.3. Internet Layer Protocols................................26
5.4. Internet Layer Forwarding...............................27 5.4. Internet Layer Forwarding...............................27
5.5. Transport Layer.........................................28 5.5. Transport Layer.........................................28
5.6. Application Layer -- Routing Protocols..................28 5.6. Application Layer -- Routing Protocols..................28
5.7. Application Layer -- Network Management Protocol........28 5.7. Application Layer -- Network Management Protocol........29
6. Summary......................................................29 6. Summary......................................................29
7. Acknowledgements.............................................29 7. Acknowledgements.............................................29
8. Security Considerations......................................29 8. Security Considerations......................................29
8.1. Analysis of Potential Threats Introduced by ForCES......30 8.1. Analysis of Potential Threats Introduced by ForCES......30
8.1.1. "Join" or "Remove" Message Flooding on CEs.........30 8.1.1. "Join" or "Remove" Message Flooding on CEs.........30
8.1.2. Impersonation Attack...............................30 8.1.2. Impersonation Attack...............................30
8.1.3. Replay Attack......................................30 8.1.3. Replay Attack......................................31
8.1.4. Attack during Fail Over............................31 8.1.4. Attack during Fail Over............................31
8.1.5. Data Integrity.....................................31 8.1.5. Data Integrity.....................................31
8.1.6. Data Confidentiality...............................31 8.1.6. Data Confidentiality...............................32
8.1.7. Sharing security parameters........................32 8.1.7. Sharing security parameters........................32
8.1.8. Denial of Service Attack via External Interface....32 8.1.8. Denial of Service Attack via External Interface....32
8.2. Security Recommendations for ForCES.....................32 8.2. Security Recommendations for ForCES.....................32
8.2.1. Security Configuration.............................33 8.2.1. Security Configuration.............................33
8.2.2. Using TLS with ForCES..............................33 8.2.2. Using TLS with ForCES..............................34
8.2.3. Using IPsec with ForCES............................34 8.2.3. Using IPsec with ForCES............................35
9. Normative References.........................................36 9. Normative References.........................................36
10. Informative References......................................36 10. Informative References......................................37
11. Authors' Addresses..........................................37 11. Authors' Addresses..........................................37
12. Intellectual Property Right.................................38 12. Intellectual Property Right.................................38
13. Full Copyright Statement....................................38 13. Full Copyright Statement....................................39
Conventions used in this document 1. Definitions
1.1. Conventions used in this document
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
1. Definitions 1.2. Terminologies
A set of terminology associated with the ForCES requirements is A set of terminology associated with the ForCES requirements is
defined in [3] and we only include the definitions that are most defined in [3] and we only include the definitions that are most
relevant to this document here. relevant to this document here.
Addressable Entity (AE) - An entity that is directly addressable Addressable Entity (AE) - An entity that is directly addressable
given some interconnect technology. For example, on IP networks, given some interconnect technology. For example, on IP networks,
it is a device to which we can communicate using an IP address; on it is a device to which we can communicate using an IP address; on
a switch fabric, it is a device to which we can communicate using a a switch fabric, it is a device to which we can communicate using a
switch fabric port number. switch fabric port number.
skipping to change at page 11, line 31 skipping to change at page 11, line 37
physical FE into multiple logical FEs. It is also possible for one physical FE into multiple logical FEs. It is also possible for one
FE to use multiple physical FEs. The mapping between physical FE to use multiple physical FEs. The mapping between physical
FE(s) and the logical FE(s) is beyond the scope of ForCES. For FE(s) and the logical FE(s) is beyond the scope of ForCES. For
example, a logical partition of a physical FE can be created by example, a logical partition of a physical FE can be created by
assigning some portion of each of the resources (e.g., ports, assigning some portion of each of the resources (e.g., ports,
memory, forwarding table entries) available on the physical FE to memory, forwarding table entries) available on the physical FE to
each of the logical FEs. Such concept of FE virtualization is each of the logical FEs. Such concept of FE virtualization is
analogous to a virtual switching element as described in [8]. If analogous to a virtual switching element as described in [8]. If
FE virtualization occurs only in the pre-association phase, it has FE virtualization occurs only in the pre-association phase, it has
no impact on ForCES. However, if FE virtualization results in no impact on ForCES. However, if FE virtualization results in
dynamic resource change on FE during post-associaiton phase, the FE dynamic resource change on FE during post-association phase, the FE
model needs to be able to report such capability and the ForCES model needs to be able to report such capability and the ForCES
protocol needs to be able to inform the CE of such change via protocol needs to be able to inform the CE of such change via
asynchronous messages (see [3], Section 5, requirement #6). asynchronous messages (see [3], Section 5, requirement #6).
FEs perform all packet processing functions as directed by CEs. FEs perform all packet processing functions as directed by CEs.
FEs have no initiative of their own. Instead, FEs are slaves and FEs have no initiative of their own. Instead, FEs are slaves and
only do as they are told. FEs may communicate with one or more CEs only do as they are told. FEs may communicate with one or more CEs
concurrently across reference point Fp. FEs have no notion of CE concurrently across reference point Fp. FEs have no notion of CE
redundancy, load sharing, or distributed control. Instead, FEs redundancy, load sharing, or distributed control. Instead, FEs
accept commands from any CE authorized to control them, and it is accept commands from any CE authorized to control them, and it is
skipping to change at page 12, line 7 skipping to change at page 12, line 13
load sharing or distributed control. The idea is to keep FEs as load sharing or distributed control. The idea is to keep FEs as
simple and dumb as possible so that FEs can focus their resource on simple and dumb as possible so that FEs can focus their resource on
the packet processing functions. the packet processing functions.
For example, in Figure 5, FE1 and FE2 can be configured to accept For example, in Figure 5, FE1 and FE2 can be configured to accept
commands from both the primary CE (CE1) and the backup CE (CE2). commands from both the primary CE (CE1) and the backup CE (CE2).
Upon detection of CE1 failure, perhaps across the Fr or Fp Upon detection of CE1 failure, perhaps across the Fr or Fp
reference point, CE2 is configured to take over activities of CE1. reference point, CE2 is configured to take over activities of CE1.
This is beyond the scope of ForCES and is not discussed further. This is beyond the scope of ForCES and is not discussed further.
Distributed control can be achieved in the similar fashion, without Distributed control can be achieved in a similar fashion, without
much intelligence on the part of FEs. For example, FEs can be much intelligence on the part of FEs. For example, FEs can be
configured to detect RSVP and BGP protocol packets, and forward configured to detect RSVP and BGP protocol packets, and forward
RSVP packets to one CE and BGP packets to another CE. Hence, FEs RSVP packets to one CE and BGP packets to another CE. Hence, FEs
may need to do packet filtering for forwarding packets to specific may need to do packet filtering for forwarding packets to specific
CEs. CEs.
------- Fr ------- ------- Fr -------
| CE1 | ------| CE2 | | CE1 | ------| CE2 |
------- ------- ------- -------
| \ / | | \ / |
skipping to change at page 17, line 43 skipping to change at page 18, line 4
Post-association phase is the period of time during which an FE and Post-association phase is the period of time during which an FE and
CE have been configured with information necessary to contact each CE have been configured with information necessary to contact each
other and includes both association establishment and steady-state other and includes both association establishment and steady-state
communication. The communication between CE and FE is performed communication. The communication between CE and FE is performed
across the Fp ("p" meaning protocol) reference point. ForCES across the Fp ("p" meaning protocol) reference point. ForCES
protocol is exclusively used for all communication across the Fp protocol is exclusively used for all communication across the Fp
reference point. reference point.
4.2.1. Proximity and Interconnect between CEs and FEs 4.2.1. Proximity and Interconnect between CEs and FEs
The ForCES Working Group has made a conscious decision that the The ForCES Working Group has made a conscious decision that the
first version of ForCES will be focused on "very close" CE/FE first version of ForCES will be focused on "very close" CE/FE
localities in IP networks. Very Close localities consist of control localities in IP networks. Very Close localities consist of
and forwarding elements that either are components in the same control and forwarding elements that either are components in the
physical box, or are separated at most by one local network hop same physical box, or are separated at most by one local network
([7]). CEs and FEs can be connected by a variety of interconnect hop ([7]). CEs and FEs can be connected by a variety of
technologies, including Ethernet connections, backplanes, ATM interconnect technologies, including Ethernet connections,
(cell) fabrics, etc. ForCES should be able to support each of backplanes, ATM (cell) fabrics, etc. ForCES should be able to
these interconnects (see [3] Section 5, requirement #1). When the support each of these interconnects (see [3] Section 5, requirement
CEs and FEs are separated beyond a single L3 routing hop, the #1). When the CEs and FEs are separated beyond a single L3 routing
ForCES protocol will make use of an existing RFC2914 compliant L4 hop, the ForCES protocol will make use of an existing RFC2914
protocol with adequate reliability, security and congestion control compliant L4 protocol with adequate reliability, security and
(e.g. TCP, SCTP) for transport purposes. congestion control (e.g. TCP, SCTP) for transport purposes.
4.2.2. Association Establishment 4.2.2. Association Establishment
FE CE FE CE
| | | |
|(Security exchange.) | |(Security exchange.) |
1|<--------------------->| 1|<--------------------->|
| | | |
|(Let me join the NE please.) |(Let me join the NE please.)
2|---------------------->| 2|---------------------->|
skipping to change at page 23, line 33 skipping to change at page 23, line 39
the forwarding tables across the restarts. A timer must be the forwarding tables across the restarts. A timer must be
included so that the timeout causes such cached state to expire included so that the timeout causes such cached state to expire
eventually. Those timers should be settable by the CE. eventually. Those timers should be settable by the CE.
4.3.2. FE restart 4.3.2. FE restart
In the same example in Figure 5, assuming CE1 is the working CE for In the same example in Figure 5, assuming CE1 is the working CE for
the moment, what would happen if one of the FEs, say FE1, leaves the moment, what would happen if one of the FEs, say FE1, leaves
the NE temporarily? FE1 may voluntarily decide to leave the the NE temporarily? FE1 may voluntarily decide to leave the
association. Alternatively, FE1 may stop functioning simply due to association. Alternatively, FE1 may stop functioning simply due to
unexpected failure. In former case, CE1 receives a "leave- unexpected failure. In the former case, CE1 receives a "leave-
association request" from FE1. In the latter, CE1 detects the association request" from FE1. In the latter, CE1 detects the
failure of FE1 by some other means. In both cases, CE1 must inform failure of FE1 by some other means. In both cases, CE1 must inform
the routing protocols of such an event, most likely prompting a the routing protocols of such an event, most likely prompting a
reachability and SPF (Shortest Path First) recalculation and reachability and SPF (Shortest Path First) recalculation and
associated downloading of new FIBs from CE1 to the other remaining associated downloading of new FIBs from CE1 to the other remaining
FEs (only FE2 in this example). Such recalculation and FIB update FEs (only FE2 in this example). Such recalculation and FIB update
will also be propagated from the CE1 to its neighbors that are will also be propagated from CE1 to the NE's neighbors that are
affected by the connectivity of FE1. affected by the connectivity of FE1.
When FE1 decides to rejoin again, or when it restarts again from When FE1 decides to rejoin again, or when it restarts again from
the failure, FE1 needs to re-discover its master (CE). This can be the failure, FE1 needs to re-discover its master (CE). This can be
achieved by several means. It may re-enter the pre-association achieved by several means. It may re-enter the pre-association
phase and get that information from its FE manager. It may phase and get that information from its FE manager. It may
retrieve the previous CE information from its cache, if it can retrieve the previous CE information from its cache, if it can
validate the information freshness. Once it discovers its CE, it validate the information freshness. Once it discovers its CE, it
starts message exchange with CE to re-establish the association starts message exchange with the CE to re-establish the association
just as outlined in Figure 9, with the possible exception that it just as outlined in Figure 9, with the possible exception that it
might be able to bypass the transport of the complete initial might be able to bypass the transport of the complete initial
configuration. Suppose that FE1 still has its routing table and configuration. Suppose that FE1 still has its routing table and
other state information from the last association, instead of other state information from the last association. Instead of
sending all the information again from scratch, it may be able to sending all the information again from scratch, it may be able to
use more efficient mechanism to re-sync up the state with its CE if use more efficient mechanism to re-sync up the state with its CE if
such mechanism is supported by the ForCES protocol. For example, such mechanism is supported by the ForCES protocol. For example,
CRC-32 of the state might give a quick indication of whether or not CRC-32 of the state might give a quick indication of whether or not
the state is in-sync with its CE. By comparing its state with CE the state is in-sync with its CE. By comparing its state with the
first, it sends information update only if it is needed. ForCES CE first, it sends an information update only if it is needed.
protocol may choose to implement similar optimization mechanisms, ForCES protocol may choose to implement similar optimization
but it may also choose not to, as this is not a requirement. mechanisms, but it may also choose not to, as this is not a
requirement.
5. Applicability to RFC1812 5. Applicability to RFC1812
[3] Section 5, requirement #9 dictates "Any proposed ForCES [3] Section 5, requirement #9 dictates "Any proposed ForCES
architecture must explain how that architecture supports all of the architecture must explain how that architecture supports all of the
router functions as defined in RFC1812." RFC1812 discusses many router functions as defined in RFC1812." RFC1812 discusses many
important requirements for IPv4 routers from the link layer to the important requirements for IPv4 routers from the link layer to the
application layer. This section addresses the relevant application layer. This section addresses the relevant
requirements in RFC1812 for implementing IPv4 routers based on requirements in RFC1812 for implementing IPv4 routers based on
ForCES architecture and explains how ForCES satisfies these ForCES architecture and explains how ForCES satisfies these
skipping to change at page 28, line 49 skipping to change at page 29, line 9
more FEs than CEs in a router, the off-loaded Hello packets are more FEs than CEs in a router, the off-loaded Hello packets are
processed in a much more distributed and scalable fashion. By processed in a much more distributed and scalable fashion. By
expressing such off-loaded functions in the FE model, we can ensure expressing such off-loaded functions in the FE model, we can ensure
interoperability. However, the exact description of the off-loaded interoperability. However, the exact description of the off-loaded
functionality corresponding to the off-loaded functions expressed functionality corresponding to the off-loaded functions expressed
in the FE model are not part of the model itself and will need to in the FE model are not part of the model itself and will need to
be worked out as a separate specification. be worked out as a separate specification.
5.7. Application Layer -- Network Management Protocol 5.7. Application Layer -- Network Management Protocol
RFC1812 also dictates "Routers MUST be manageable by SNMP." (see RFC1812 also dictates "Routers MUST be manageable by SNMP." In
[4] Section 8) In general, for post-association phase, most general, for post-association phase, most external management tasks
external management tasks (including SNMP) should be done through (including SNMP) should be done through interaction with the CE in
interaction with the CE in order to support the appearance of a order to support the appearance of a single functional device.
single functional device. Therefore, it is recommended that SNMP Therefore, it is recommended that SNMP agent be implemented by CEs
management agent be implemented by CEs and the SNMP messages and the SNMP messages received by FEs be redirected to their CEs.
received by FEs be redirected to their CEs. AgentX framework AgentX framework defined in RFC2741 ([5]) may be applied here such
defined in RFC2741 ([5]) may be applied here such that CEs act in that CEs act in the role of master agent to process SNMP protocol
the role of master agent to process SNMP protocol messages while messages while FEs act in the role of subagent to provide access to
FEs act in the role of subagent to provide access to the MIB the MIB objects residing on FEs. AgentX protocol messages between
objects residing on FEs. AgentX protocol messages between the the master agent (CE) and the subagent (FE) are encapsulated and
master agent (CE) and the subagent (FE) are encapsulated and
transported via ForCES, just like data packets from any other transported via ForCES, just like data packets from any other
application layer protocols. application layer protocols.
6. Summary 6. Summary
This document defines an architectural framework for ForCES. It This document defines an architectural framework for ForCES. It
identifies the relevant components for a ForCES network element, identifies the relevant components for a ForCES network element,
including (one or more) FEs, (one or more) CEs, one optional FE including (one or more) FEs, (one or more) CEs, one optional FE
manager, and one optional CE manager. It also identifies the manager, and one optional CE manager. It also identifies the
interaction among these components and discusses all the major interaction among these components and discusses all the major
skipping to change at page 33, line 12 skipping to change at page 33, line 17
standard security protocols that can work with the common transport standard security protocols that can work with the common transport
candidates suitable for ForCES. candidates suitable for ForCES.
We review two existing security protocol solutions, namely IPsec We review two existing security protocol solutions, namely IPsec
(IP Security) [14] or TLS (Transport Layer Security) [13]. TLS (IP Security) [14] or TLS (Transport Layer Security) [13]. TLS
works with reliable transports such as TCP or SCTP for unicast, works with reliable transports such as TCP or SCTP for unicast,
while IPsec can be used with any transport (UDP, TCP, SCTP) and while IPsec can be used with any transport (UDP, TCP, SCTP) and
supports both unicast and multicast. Both TLS and IPsec can be supports both unicast and multicast. Both TLS and IPsec can be
used potentially to satisfy all of the security requirements for used potentially to satisfy all of the security requirements for
ForCES protocol. Other approaches may be used as well but are not ForCES protocol. Other approaches may be used as well but are not
documented here. documented here, including using L2 security mechanisms for a given
L2 interconnect technology, as long as the requirements can be
satisfied.
When ForCES is deployed between CEs and FEs inside a box, When ForCES is deployed between CEs and FEs inside a box,
authentication, confidentiality and integrity may be provided by authentication, confidentiality and integrity may be provided by
the physical security of the box and so the security mechanisms may the physical security of the box and so the security mechanisms may
be turned off, depending on the networking topology and its be turned off, depending on the networking topology and its
administration policy. However, it is important to realize that administration policy. However, it is important to realize that
even if the NE is in a single-box, the DoS attacks as described in even if the NE is in a single-box, the DoS attacks as described in
Section 8.1.8 can still be launched through Fi/f interfaces. Section 8.1.8 can still be launched through Fi/f interfaces.
Therefore, it is important to have the corresponding counter- Therefore, it is important to have the corresponding counter-
measurement in place even for single-box deployment. measurement in place even for single-box deployment.
skipping to change at page 36, line 46 skipping to change at page 37, line 7
[2] Floyd, S., "Congestion Control Principles", RFC 2914, September [2] Floyd, S., "Congestion Control Principles", RFC 2914, September
2000. 2000.
[3] Khosravi, H. et al., "Requirements for Separation of IP Control [3] Khosravi, H. et al., "Requirements for Separation of IP Control
and Forwarding", work in progress, May 2003, <draft-ietf-forces- and Forwarding", work in progress, May 2003, <draft-ietf-forces-
requirements-09.txt>. requirements-09.txt>.
10. Informative References 10. Informative References
[4] Case, J., et al., "A Simple Network Management Protocol [4] Case, J., et al., "Introduction and Applicability Statements
(SNMP)", RFC 1157, May 1990. for Internet Standard Management Framework", RFC 3410, December
2002.
[5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol [5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol
Version 1", RFC 2741, January 2000. Version 1", RFC 2741, January 2000.
[6] Chan, K. et al., "COPS Usage for Policy Provisioning (COPS- [6] Chan, K. et al., "COPS Usage for Policy Provisioning (COPS-
PR)", RFC 3084, March 2001. PR)", RFC 3084, March 2001.
[7] Crouch, A. et al., "ForCES Applicability Statement", work in [7] Crouch, A. et al., "ForCES Applicability Statement", work in
progress, June 2002, <draft-ietf-forces-applicability-00.txt>. progress, June 2002, <draft-ietf-forces-applicability-00.txt>.
 End of changes. 

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