draft-ietf-forces-applicability-04.txt   draft-ietf-forces-applicability-05.txt 
Alan Crouch Alan Crouch
Internet Draft Hormuzd Khosravi Internet Draft Hormuzd Khosravi
Document: draft-ietf-forces-applicability- Intel Corp. Document: draft-ietf-forces-applicability- Intel Corp.
04.txt 05.txt
Expires: July 2006 Mark Handley Expires: January 2007 Mark Handley
Working Group: ForCES ICIR Working Group: ForCES ICIR
Avri Doria Avri Doria
ETRI ETRI
ForCES Applicability Statement ForCES Applicability Statement
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
skipping to change at page 2, line 4 skipping to change at page 2, line 7
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Conventions used in this document 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 [2]. this document are to be interpreted as described in [2].
Abstract Abstract
The ForCES protocol defines a standard framework and mechanism for The ForCES protocol defines a standard framework and mechanism for
the interconnection between Control Elements and Forwarding Elements the interconnection between Control Elements and Forwarding Elements
in IP routers and similar devices. In this document we describe the in IP routers and similar devices. In this document we describe the
applicability of the ForCES model and protocol. We provide example applicability of the ForCES model and protocol. We provide example
deployment scenarios and functionality, as well as document deployment scenarios and functionality, as well as document
applications that would be inappropriate for ForCES. applications that would be inappropriate for ForCES.
Table of Contents Table of Contents
1. Purpose.........................................................3 1. Purpose........................................................3
2. Overview........................................................3 2. Overview.......................................................3
3. Terminology.....................................................3 3. Terminology....................................................3
4. Applicability to IP Networks....................................3 4. Applicability to IP Networks...................................3
4.1. Applicable Services...........................................4 4.1. Applicable Services.........................................4
4.1.1. Discovery, Capability Information Exchange..................4 4.1.1. Discovery, Capability Information Exchange................4
4.1.2. Topology Information Exchange...............................5 4.1.2. Topology Information Exchange.............................5
4.1.3. Configuration...............................................5 4.1.3. Configuration.............................................5
4.1.4. Routing Exchange............................................5 4.1.4. Routing Exchange..........................................5
4.1.5. QoS Exchange................................................5 4.1.5. QoS Exchange..............................................5
4.1.6. Security Exchange...........................................5 4.1.6. Security Exchange.........................................5
4.1.7. Filtering Exchange and Firewalls............................6 4.1.7. Filtering Exchange and Firewalls..........................6
4.1.8. Encapsulation, Tunneling Exchange...........................6 4.1.8. Encapsulation, Tunneling Exchange.........................6
4.1.9. NAT and Application-level Gateways..........................6 4.1.9. NAT and Application-level Gateways........................6
4.1.10. Measurement and Accounting.................................6 4.1.10. Measurement and Accounting................................6
4.1.11. Diagnostics................................................6 4.1.11. Diagnostics...............................................6
4.1.12. CE Redundancy or CE Failover...............................6 4.1.12. CE Redundancy or CE Failover..............................6
4.2. CE-FE Link Capability.........................................7 4.2. CE-FE Link Capability.......................................7
4.3. CE/FE Locality................................................7 4.3. CE/FE Locality..............................................7
5. Limitations and Out-of-Scope Items..............................7 5. Limitations and Out-of-Scope Items.............................7
5.1. Out of Scope Services.........................................8 5.1. Out of Scope Services.......................................8
5.1.1. Label Switching.............................................8 5.1.1. Label Switching...........................................8
5.1.2. Separation of Control and Forwarding in Multimedia Gateways.8 5.1.2. Separation of Control and Forwarding in Multimedia Gateways8
5.2. Localities....................................................8 5.2. Localities..................................................8
6. Security Considerations.........................................9 6. Security Considerations........................................9
7. ForCES Manageability............................................9 7. ForCES Manageability...........................................9
7.1. NE as an atomic element.......................................9 7.1. NE as an atomic element.....................................9
7.2. NE as composed of manageable elements.........................9 7.2. NE as composed of manageable elements.......................9
7.3. ForCES Protocol MIB..........................................10 7.3. ForCES Protocol MIB........................................10
7.3.1. MIB Management of an FE....................................10 7.3.1. MIB Management of an FE..................................10
7.4. The FEM and CEM..............................................11 7.4. CE to CE communication.....................................11
8. References.....................................................11 7.5. The FEM and CEM............................................11
8.1. Normative References.........................................11 8. References....................................................12
8.2. Informative References.......................................12 8.1. Normative References.......................................12
9. Acknowledgments................................................12 8.2. Informative References.....................................12
10. Authors' Addresses............................................12 9. Acknowledgments...............................................12
10. Authors' Addresses..........................................12
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 intent of the ForCES protocol designers as to how the protocol
should be used. The Applicability Statement will evolve alongside should be used. The Applicability Statement will evolve alongside
the protocol, and will go to RFC as informational around the same the protocol, and will go to RFC as informational around the same
time the as the protocol goes to RFC. time the as the protocol goes to RFC.
2. Overview 2. Overview
skipping to change at page 9, line 23 skipping to change at page 9, line 27
CE and FE administered independently, we strongly discourage such CE and FE administered independently, we strongly discourage such
uses, because they would require a significantly different trust uses, because they would require a significantly different trust
model from that ForCES assumes. model from that ForCES assumes.
7. ForCES Manageability 7. ForCES Manageability
From the management perspective, an NE can be viewed in at least two From the management perspective, an NE can be viewed in at least two
ways. From one perspective, it is a single network element, ways. From one perspective, it is a single network element,
specifically a router that needs to be managed in essentially the specifically a router that needs to be managed in essentially the
same way any router is managed. From another perspective element same way any router is managed. From another perspective element
management can view the individual entities and interfaces that make management can view the individual entities and interfaces that make
of a ForCES NE. up a ForCES NE.
7.1.NE as an atomic element 7.1.NE as an atomic element
From the ForCES requirements RFC [RFC 3654], Section 4, point 4: From the ForCES requirements RFC [RFC 3654], Section 4, point 4:
A NE MUST support the appearance of a single functional device. A NE MUST support the appearance of a single functional device.
As a single functional device a ForCES NE runs protocols and each of As a single functional device a ForCES NE runs protocols and each of
the protocols has it own existing manageability aspects which are the protocols has it own existing manageability aspects that are
document elsewhere. As a router it would also have a configuration document elsewhere. As a router it would also have a configuration
interface. When viewed in this manner, the NE is controlled as interface. When viewed in this manner, the NE is controlled as
single routing entity and no new management beyond what is already single routing entity and no new management beyond what is already
available for routers and routing protocols would be required for a available for routers and routing protocols would be required for a
ForCES NE. ForCES NE.
7.2.NE as composed of manageable elements 7.2.NE as composed of manageable elements
When viewed as a decomposed set of elements from the management When viewed as a decomposed set of elements from the management
perspective, the ForCES NE is divided into a set of one of more perspective, the ForCES NE is divided into a set of one of more
Control Elements, Forwarding Elements and the interfaces between Control Elements, Forwarding Elements and the interfaces between
them. The interface functionality between the CE and the FE is them. The interface functionality between the CE and the FE is
provided by the ForCES protocol. As with all IETF protocols a MIB provided by the ForCES protocol. As with all IETF protocols a MIB
is provided for the purposes of managing the protocol. is provided for the purposes of managing the protocol.
Additionally the architecture make provision for configuration Additionally the architecture makes provision for configuration
control of the individual CEs and FEs. This is handled by elements control of the individual CEs and FEs. This is handled by elements
names FE manager and the CE manager. Specifically from the ForCES named FE manager (FEM) and the CE manager (CEM). Specifically from
requirements the ForCES requirements
RFC [RFC 3654], Section 4, point 4: RFC [RFC 3654], Section 4, point 4:
However, external entities (e.g., FE managers and CE managers) MAY However, external entities (e.g., FE managers and CE managers)
have direct access to individual ForCES protocol elements for MAY have direct access to individual ForCES protocol elements
providing information to transition them from the pre-association to for providing information to transition them from the
post-association phase. pre-association to post-association phase.
7.3.ForCES Protocol MIB 7.3.ForCES Protocol MIB
From the ForCES MIB RFC [TBD], section X From the ForCES MIB RFC [TBD], section X
The ForCES MIB is a primarily read-only MIB that captures The ForCES MIB is a primarily read-only MIB that captures
information related to the ForCES protocol. This includes state information related to the ForCES protocol. This includes
information about the associations between CE(s) and FE(s) in the state information about the associations between CE(s) and
NE. FE(s) in the NE.
The ForCES MIB does not include information that is specified in The ForCES MIB does not include information that is specified in
other MIBs, such as packet counters for interfaces, etc. other MIBs, such as packet counters for interfaces, etc.
More specifically, the information in the ForCES MIB relative to More specifically, the information in the ForCES MIB relative to
associations includes: associations includes:
- identifiers of the elements in the association - identifiers of the elements in the association
- state of the association - state of the association
- configuration parameters of the association - configuration parameters of the association
- statistics of the association - statistics of the association
7.3.1.MIB Management of an FE 7.3.1.MIB Management of an FE
While it is possible to manage a FE from a element manager, several While it is possible to manage a FE from a element manager, several
requirements relating to this have been included in the ForCES requirements relating to this have been included in the ForCES
Requirements. Requirements.
From the ForCES Requirements [RFC 3654], Section 4, point 14: From the ForCES Requirements [RFC 3654], Section 4, point 14:
1. The ability for a management tool (e.g., SNMP) to be used to read 1. The ability for a management tool (e.g., SNMP) to be used
(but not change) the state of FE SHOULD NOT be precluded. to read (but not change) the state of FE SHOULD NOT be
precluded.
2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to 2. It MUST NOT be possible for management tools
change the state of a FE in a manner that affects overall NE (e.g., SNMP, etc) to change the state of a FE in a manner
behavior without the CE being notified. that affects overall NE behavior without the CE being
notified.
The ForCES Requirements [RFC 3746], Section 5.7, goes further in The ForCES Requirements [RFC 3746], Section 5.7, goes further in
discussing the manner in which FEs should handle management requests discussing the manner in which FEs should handle management requests
that are specifically directed to the FE: that are specifically directed to the FE:
RFC 1812 [2] also dictates that "Routers MUST be manageable by RFC 1812 [2] also dictates that "Routers MUST be manageable
SNMP". In general, for the post-association phase, most external by SNMP". In general, for the post-association phase, most
management tasks (including SNMP) should be done through interaction external management tasks (including SNMP) should be done
with the CE in order to support the appearance of a single through interaction with the CE in order to support the
functional device. Therefore, it is recommended that an SNMP agent appearance of a single functional device. Therefore, it is
be implemented by CEs and that the SNMP messages received by FEs be recommended that an SNMP agent be implemented by CEs and
redirected to their CEs. AgentX framework defined in RFC 2741 ([6]) that the SNMP messages received by FEs be redirected to their
may be applied here such that CEs act in the role of master agent to CEs. AgentX framework defined in RFC 2741 ([6]) may be applied
process SNMP protocol messages while FEs act in the role of subagent here such that CEs act in the role of master agent to process
SNMP protocol messages while FEs act in the role of subagent
to provide access to the MIB objects residing on FEs. AgentX to provide access to the MIB objects residing on FEs. AgentX
protocol messages between the master agent (CE) and the subagent protocol messages between the master agent (CE) and the
(FE) are encapsulated and transported via ForCES, just like data subagent (FE) are encapsulated and transported via ForCES,
packets from any other application layer protocols. just like data packets from any other application layer
protocols.
7.4.The FEM and CEM 7.4. CE to CE communication
The ForCES architecture allows for multiple CEs within a single NE.
The operating presumption is that the CEs will coordinate their
efforts in those cases where multiple CEs are available. Currently
the only specified method for CE to interact with FE is for there to
be one master CE, though there can be many backup CEs. Other
solutions that have been discussed include having multiple
specialist CEs per FE, however, the protocol does not support this
option.
The creation of a protocol or method for CE coordination is out of
scope for the initial ForCES specification effort. Any NE that uses
multiple CEs for reliability must provide its own coordination
mechanisms.
7.5. The FEM and CEM
Though out of scope for the initial ForCES specification effort, the Though out of scope for the initial ForCES specification effort, the
ForCES architecture include two entities, the CE Manager (CEM) and ForCES architecture include two entities, the CE Manager (CEM) and
the FE Manager (FEM) the FE Manager (FEM)
From the ForCES Protocols Specification [RFCXXXX] From the ForCES Protocols Specification [RFCXXXX]
CE Manager (CEM) - A logical entity responsible for generic CE CE Manager (CEM) - A logical entity responsible for generic CE
management tasks. It is particularly used during the pre- management tasks. It is particularly used during the
association phase to determine with which FE(s) a CE should pre-association phase to determine with which FE(s) a CE
communicate. should communicate.
FE Manager (FEM) - A logical entity responsible for generic FE FE Manager (FEM) - A logical entity responsible for generic
management tasks. It is used during pre-association phase to FE management tasks. It is used during pre-association phase
determine with which CE(s) an FE should communicate. to determine with which CE(s) an FE should communicate.
8. References 8. References
8.1.Normative References 8.1.Normative References
1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC
October 1996. 2026, October 1996.
2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997. Levels", RFC2119 (BCP), IETF, March 1997.
3. Khosravi, et al., ’’Requirements for Separation of IP Control and 3. Khosravi, et al., ’’Requirements for Separation of IP Control and
Forwarding”, RFC 3654, November 2003. Forwarding”, RFC 3654, November 2003.
4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746, 4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746,
April 2004. April 2004.
 End of changes. 17 change blocks. 
76 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/