Alan
forces                                                         A. Crouch
   Internet Draft                                      Hormuzd
Internet-Draft                                               H. Khosravi
   Document: draft-ietf-forces-applicability-
Intended status: Informational                                     Intel Corp.
   05.txt
Expires: January 2007                                   Mark Handley
   Working Group: ForCES                                           ICIR
                                                             Avri 3, 2010                                        A. Doria
                                                                   ETRI
                                                                     LTU
                                                                 X. Wang
                                                                  Huawei
                                                                K. Ogawa
                                                         NTT Corporation
                                                            July 2, 2009

                     ForCES Applicability Statement
                   draft-ietf-forces-applicability-06

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of which he BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or she is aware
   have been IETF Contributions published or will made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be disclosed, modified outside the IETF Standards Process, and any
   derivative works of which he or she becomes
   aware will it may not be disclosed, in accordance with Section 6 of BCP 79. created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work "work in
   progress.'' progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 3, 2010.

Copyright Notice

   Copyright (C) The Internet Society (2006).

  Conventions used in this (c) 2009 IETF Trust and the persons identified as the
   document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", authors.  All rights reserved.

   This document is subject to BCP 78 and "OPTIONAL" the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document are to be interpreted (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as described in [2]. they describe your rights
   and restrictions with respect to this document.

Abstract

   The ForCES protocol defines a standard framework and mechanism for
   the interconnection between Control Elements and Forwarding Elements
   in IP routers and similar devices.  In this document we describe the
   applicability of the ForCES model and protocol.  We provide example
   deployment scenarios and functionality, as well as document
   applications that would be inappropriate for ForCES.

Table of Contents

   1. Purpose........................................................3  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Overview.......................................................3  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3. Terminology....................................................3  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Applicability to IP Networks...................................3 Networks . . . . . . . . . . . . . . . . .  4
     4.1.  Applicable Services.........................................4 Services  . . . . . . . . . . . . . . . . . . .  5
       4.1.1.  Discovery, Capability Information Exchange................4 Exchange . . . . . .  5
       4.1.2.  Topology Information Exchange.............................5 Exchange  . . . . . . . . . . . .  6
       4.1.3.  Configuration.............................................5  Configuration  . . . . . . . . . . . . . . . . . . . .  6
       4.1.4.  Routing Exchange..........................................5 Exchange . . . . . . . . . . . . . . . . . . .  6
       4.1.5.  QoS Exchange..............................................5 Exchange . . . . . . . . . . . . . . . . . . . . .  6
       4.1.6.  Security Exchange.........................................5 Exchange  . . . . . . . . . . . . . . . . . .  6
       4.1.7.  Filtering Exchange and Firewalls..........................6 Firewalls . . . . . . . . . . .  7
       4.1.8.  Encapsulation, Tunneling Exchange.........................6 Exchange  . . . . . . . . . .  7
       4.1.9.  NAT and Application-level Gateways........................6 Gateways . . . . . . . . . .  7
       4.1.10. Measurement and Accounting................................6 Accounting . . . . . . . . . . . . . .  7
       4.1.11. Diagnostics...............................................6 Diagnostics  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.12. CE Redundancy or CE Failover..............................6 Failover . . . . . . . . . . . . .  7
     4.2.  CE-FE Link Capability.......................................7 Capability  . . . . . . . . . . . . . . . . . .  7
     4.3.  CE/FE Locality..............................................7 Locality . . . . . . . . . . . . . . . . . . . . . .  8
   5. Limitations and Out-of-Scope Items.............................7
   5.1.  Out of Scope Services.......................................8
   5.1.1.  Label Switching...........................................8
   5.1.2.  Separation of Control and Forwarding in Multimedia Gateways8
   5.2.  Localities..................................................8
   6.  Security Considerations........................................9
   7. Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  ForCES Manageability...........................................9
   7.1. Manageability . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  NE as an atomic element.....................................9
   7.2. element  . . . . . . . . . . . . . . . . .  9
     6.2.  NE as composed of manageable elements.......................9
   7.3. elements  . . . . . . . . . .  9
     6.3.  ForCES Protocol MIB........................................10
   7.3.1. MIB  . . . . . . . . . . . . . . . . . . . 10
       6.3.1.  MIB Management of an FE..................................10
   7.4.  CE to CE communication.....................................11
   7.5. FE  . . . . . . . . . . . . . . . 10
     6.4.  The FEM and CEM............................................11 CEM  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8. References....................................................12
   8.1.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References.......................................12
   8.2. References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References.....................................12
   9. Acknowledgments...............................................12
   10. References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses..........................................12 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

1.  Purpose

   The purpose of the ForCES Applicability Statement is to capture the
   intent of the ForCES protocol [I-D.ietf-forces-protocol] designers as
   to how the protocol
   should could be used.  The Applicability Statement will evolve alongside
   the protocol, and will go to RFC as informational around the same
   time the as used (in conjunction with the protocol goes to RFC. ForCES
   model [I-D.ietf-forces-model]).

2.  Overview

   The ForCES protocol defines a standard framework and mechanism for
   the exchange of information between the logically separate
   functionality of the control and data forwarding planes of IP routers
   and similar devices.  It focuses on the communication necessary for
   separation of control plane functionality such as routing protocols,
   signaling protocols, and admission control from data forwarding plane
   per-packet activities such as packet forwarding, queuing, and header
   editing.

   This document defines the applicability of the ForCES mechanisms.  It
   describes types of configurations and settings where ForCES is most
   appropriately applied.  This document also describes scenarios and
   configurations where ForCES would not be appropriate for use.

3.  Terminology

   A set of terminology associated with ForCES is defined in [3, 4].
   That terminology is reused here and the reader is directed to [3, 4]
   for the following definitions:

   o CE: Control Element.

   o FE: Forwarding Element.

   o ForCES: ForCES protocol.

   o TML: Transport Mapping Layer.

4.  Applicability to IP Networks

   The purpose of this section is to list the areas of ForCES
   applicability in IP network devices.  Relatively low performance
   devices end routing
   systems may be implemented on a simple processor hardware which performs both
   control and packet forwarding functionality.  ForCES is may not
   applicable make
   sense for such devices.

   Higher performance devices end routing systems typically distribute work amongst
   interface processors, processing elements, and these devices (FEs) therefore need
   to communicate with the control element(s) to perform their job.
   ForCES provides a standard way to do this communication.

   The remainder of this section lists the applicable services which
   ForCES may support, applicable FE functionality, applicable CE-FE
   link scenarios, and applicable topologies in which ForCES may be
   deployed.

4.1.  Applicable Services

   In this section we describe the applicability of ForCES for the
   following control-forwarding plane services:

   o Discovery, Capability Information Exchange

   o Topology Information Exchange

   o Configuration

   o Routing Exchange

   o QoS Exchange

   o Security Exchange

   o Filtering Exchange

   o Encapsulation/Tunneling Exchange

   o NAT and Application-level Gateways

   o Measurement and Accounting

   o Diagnostics

   o CE Redundancy or CE Failover

4.1.1.  Discovery, Capability Information Exchange

   Discovery is the process by which CEs and FEs learn of each other's
   existence.  ForCES assumes that CEs and FEs already know sufficient
   information to begin communication in a secure manner.  The ForCES
   protocol is only applicable after CEs and FEs have found each other.
   ForCES makes no assumption about whether discovery was performed
   using a dynamic protocol or merely static configuration.

   During the discovery phase, CEs and FEs may exchange capability
   information with each other.  For example, the FEs may express the number
   of interface ports they provide, as well as the static and
   configurable attributes of each port.

   In addition to initial configuration, the CEs and FEs may also exchange
   dynamic configuration changes using ForCES.  For example,
   FE's FEs
   asynchronously inform the CE of an increase/decrease in available
   resources or capabilities on the FE.

4.1.2.  Topology Information Exchange

   In this context, topology information relates to how the FEs are
   interconnected with each other with respect to packet forwarding.
   Whilst topology
   Topology discovery is outside the scope of the ForCES
   protocol, a standard topology discovery protocol may be selected and
   used to "learn" the topology, and then protocol.  An
   implementation can choose its own method of topology discovery(for
   example use a standard topology discovery portocol like LLDP, BFD;or
   apply a static topology configuration policy).Once the topology is
   established, ForCES protocol may be used to transmit the resulting
   information to the CE.

4.1.3.  Configuration

   ForCES is used to perform FE configuration.  For example, CEs set
   configurable FE attributes such as IP addresses, etc. for their
   interfaces.

4.1.4.  Routing Exchange

   ForCES may be used to deliver packet forwarding information resulting
   from CE routing calculations.  For example, CEs may send forwarding
   table updates to the FEs, so that they can make forwarding decisions.
   FEs may inform the CE in the event of a forwarding table miss.

4.1.5.  QoS Exchange

   ForCES may be used to exchange QoS capabilities between CEs and FEs.
   For example, an FE may express QoS capabilities to the CE.  Such
   capabilities might include metering, policing, shaping, and queuing
   functions.  The CE may use ForCES to configure these capabilities.

4.1.6.  Security Exchange

   ForCES may be used to exchange Security information between CEs and
   FEs.  For example, the FE may use ForCES to express the types of
   encryption that it is capable of using in an IPsec tunnel.  The CE
   may use ForCES to configure such a tunnel.

4.1.7.  Filtering Exchange and Firewalls

   ForCES may be used to exchange filtering information.  For example,
   Fes
   FEs may use ForCES to express the filtering functions such as
   classification and action that they can perform, and the CE may
   configure these capabilities.

4.1.8.  Encapsulation, Tunneling Exchange

   ForCES may be used to exchange encapsulation capabilities of an FE,
   such as tunneling, and the configuration of such capabilities.

4.1.9.  NAT and Application-level Gateways

   ForCES may be used to exchange configuration information for Network
   Address Translators.  Whilst ForCES is not specifically designed for
   the configuration of application-level gateway functionality, this
   may be in scope for some types of application-level gateways.

4.1.10.  Measurement and Accounting

   ForCES may be used to exchange configuration information regarding
   traffic measurement and accounting functionality.  In this area,
   ForCES may overlap somewhat with functionality provided by
   alternative network management mechanisms such as SNMP.  In some
   cases ForCES may be used to convey information to the CE to be
   reported externally using SNMP. However, in other cases it may make
   more sense for the FE to directly speak SNMP.

4.1.11.  Diagnostics

   ForCES may be used for CE's CEs and FE's FEs to exchange diagnostic
   information.  For example, an FE can send self-test results to the
   CE.

4.1.12.  CE Redundancy or CE Failover

   ForCES is a master-slave protocol where FE's are slaves

   CE failover and CE's redundancy are
   masters. out of scope in the initial version of
   ForCES protocol.  Basic mechanisms for CE redundancy/failover are provided
   in ForCES protocol. not
   presently implemented.  Broad concepts such as implementing CE
   Redundancy, CE Failover, and CE-CE communication, while not precluded
   by the ForCES architecture, are considered outside the scope of
   ForCES protocol.  ForCES protocol is designed to handle CE- FE
   communication, and is not intended for CE-CE communication.

4.2.  CE-FE Link Capability

   When using ForCES, the bandwidth of the CE-FE link is a
   consideration, and cannot be ignored.  For example, sending a full
   routing table of 110K routes is reasonable over a 100Mbit Ethernet
   interconnect, but could be non-trivial over a lower-bandwidth link.
   ForCES should be sufficiently future-proof to be applicable in
   scenarios where routing tables grow to several orders of magnitude
   greater than their current size (approximately 100K routes). size.  However, we also note that not all
   IP routers need full routing tables.

4.3.  CE/FE Locality

   We do not intend ForCES to be applicable in configurations where the
   CE and FE are located arbitrarily in the network.  In particular,

   ForCES is intended for environments where one of the following
   applies:

   o The control interconnect is some form of local bus, switch, or LAN,
   where reliability is high, closely controlled, and not susceptible to
   external disruption that does not also affect the CEs and/or FEs.

   o The control interconnect shares fate with the FE's forwarding
   function.  Typically this is because the control connection is also
   the FE's primary packet forwarding connection, and so if that link
   goes down, the FE cannot forward packets anyway.

   The key guideline is that the reliability of the device should not be
   significantly reduced by the separation of control and forwarding
   functionality.

   Taking this into account, ForCES is applicable in the following CE/FE
   localities:

   o single box NE: chassis with multiple CEs and FEs setup.  ForCES is
   applicable in localities consisting of control and forwarding
   elements which are either components in the same physical
   box, or are separated at most by one local network hop (historically
   referred to as "Very Close" localities). box.

   Example: a network element with a single control blade, and one or
   more forwarding blades, all present in the same chassis and sharing
   an interconnect such as Ethernet or PCI.  In this locality, the
   majority of the data traffic being forwarded typically does not
   traverse the same links as the ForCES control traffic.

5. Limitations

   o multiple boxes: separated CE and FE where physical locality could
   be same rack, room, building, or long distance which could span
   across continents and Out-of-Scope Items oceans.  ForCES was designed to enable logical separation is applicable in localities
   consisting of control and forwarding planes in IP network devices.  However, ForCES is not
   intended to be applicable to all services elements which are separated at
   single hop or to all possible CE/FE
   localities. multiple hops network.

5.  Security Considerations

   The purpose ForCES architecture allows for a variety of this section is security levels[6].

   When operating under a secured physical environment, or for other
   operational concerns (in some cases performance issues) the operator
   may turn off all the security functions between CE and FE.  When the
   operator makes a decision to list limitations secure the path between the FE and out-of-scope
   items for ForCES.

5.1.    Out CE
   then the operator chooses from one of Scope Services

   The following control-forwarding plane services are explicitly not
   addressed the options provided by ForCES:

   o    Label Switching

   o    Multimedia Gateway Control (MEGACO).

5.1.1.  Label Switching

   Label Switching is the purview of
   TML.  Security choices provided by the GSMP Working Group in TML take effect during the Sub-
   IP Area
   pre-association phase of the IETF.  GSMP is a general purpose protocol ForCES protocol.  An operator may choose
   to control
   a label switch.  GSMP defines mechanisms to separate the label
   switch data plane from the control plane label protocols such as LDP
   [8]. For more information on GSMP, see [7].

5.1.2.  Separation of Control and Forwarding in Multimedia Gateways

   MEGACO defines a protocol used between elements of a physically
   decomposed multimedia gateway.  Separation use all, some or none of call control channels
   from bearer channels is the purview of MEGACO.  For more information
   on MEGACO, see [9].

5.2.    Localities

   ForCES protocol was intended to work within security services provided by the localities described TML
   in the last section.  Outside these boundaries, care must be taken
   or the protocol may not work right.  Examples of localities where a CE-FE connection.  A ForCES was not originally intended NE is required to be used:

   o    Localities where there are multiple hops between CE provide CE/FE node
   authentication services, and FE.

   o    Localities where hops between the CE may provide message integrity and FE are dynamically
   routing using IP routing protocols.

   o    Localities where the loss of the CE-FE link is of non-
   negligible probability.

   o    Localities where two or more FEs controlled
   confidentially services.  The NE may provide these services by the same CE
   cannot communicate, either directly,
   employing IPSEC or indirectly via other Fes
   controlled by TLS depending on the same CE.

6. Security Considerations

   The security choice of ForCES protocol will be addressed in the Protocol
   Specification [6]. For security requirements, see architecture
   requirement #5 and protocol requirement #2 in the Requirements Draft
   [3].  The ForCES protocol assumes that the CE and FE are TML used in the same
   administration, and have shared secrets as a means
   deployment of
   administration. Whilst it might be technically feasible to have the
   CE and FE administered independently, we strongly discourage such
   uses, because they would require a significantly different trust
   model from that ForCES assumes.

7. NE.

6.  ForCES Manageability

   From the management perspective, an NE can be viewed in at least two
   ways.  From one perspective, it is a single network element,
   specifically a router that needs to be managed in essentially the
   same way any router is managed.  From another perspective element
   management can view the individual entities and interfaces that make
   up a ForCES NE.

7.1.

6.1.  NE as an atomic element

   From the ForCES requirements RFC [RFC 3654], 3654, Section 4, point 4:

   A NE MUST support the appearance of a single functional device.

   As a single functional device a ForCES NE runs protocols and each of
   the protocols has it own existing manageability aspects that are
   document elsewhere.  As a router it would also have a configuration
   interface.  When viewed in this manner, the NE is controlled as
   single routing entity and no new management beyond what is already
   available for routers and routing protocols would be required for a
   ForCES NE.

7.2.

6.2.  NE as composed of manageable elements

   When viewed as a decomposed set of elements from the management
   perspective, the ForCES NE is divided into a set of one of more
   Control Elements, Forwarding Elements and the interfaces between
   them.  The interface functionality between the CE and the FE is
   provided by the ForCES protocol.  As with all IETF protocols a MIB is
   provided for the purposes of managing the protocol.

   Additionally the architecture makes provision for configuration
   control of the individual CEs and FEs.  This is handled by elements
   named FE manager (FEM) and the CE manager (CEM).  Specifically from
   the ForCES requirements RFC [RFC 3654], Section 4, point 4:

   However, external entities (e.g., FE managers and CE managers) MAY
   have direct access to individual ForCES protocol elements for
   providing information to transition them from the pre-association to
   post-association phase.

7.3.

6.3.  ForCES Protocol MIB

   From the ForCES MIB RFC [TBD], section X

   The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB
   that captures information related to the ForCES protocol.  This
   includes state information about the associations between CE(s) and
   FE(s) in the NE.

   The ForCES MIB does not include information that is specified in
   other MIBs, such as packet counters for interfaces, etc.

   More specifically, the information in the ForCES MIB relative to
   associations includes:

   - identifiers of the elements in the association

   - state of the association

   - configuration parameters of the association

   - statistics of the association

7.3.1.

6.3.1.  MIB Management of an FE

   While it is possible to manage a FE from a element manager, several
   requirements relating to this have been included in the ForCES
   Requirements.

   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
   (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
   change the state of a FE in a manner that affects overall NE behavior
   without the CE being notified.

   The ForCES Requirements [RFC 3746], 3654], Section 5.7, goes further in
   discussing the manner in which FEs should handle management requests
   that are specifically directed to the FE:

   RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP".
   In general, for the post-association phase, most external management
   tasks (including SNMP) should be done through interaction with the CE
   in order to support the appearance of a single functional device.
   Therefore, it is recommended that an SNMP agent be implemented by CEs
   and that the SNMP messages received by FEs be redirected to their
   CEs.  AgentX framework defined in RFC 2741 ([6]) may be applied 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 protocol messages
   between the master agent (CE) and the subagent (FE) are encapsulated
   and transported via ForCES, just like data packets from any other
   application layer protocols.

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.

6.4.  The FEM and CEM

   Though out of scope for the initial ForCES specification effort, the
   ForCES architecture include two entities, the CE Manager (CEM) and
   the FE Manager (FEM) (FEM).  From the ForCES Protocols Specification [RFCXXXX]
   [I-D.ietf-forces-protocol].

   CE Manager (CEM) - A logical entity responsible for generic CE
   management tasks.  It is particularly used during the pre-association
   phase to determine with which FE(s) a CE should communicate.

   FE Manager (FEM) - A logical entity responsible for generic FE
   management tasks.  It is used during pre-association phase to
   determine with which CE(s) an FE should communicate.

7.  Contributors

   The following are the contributors who were instrumental in the
   creation of earlier releases of this document or who gave good
   suggestions to this document.

   Mark Handley,ICIR.

8.  Acknowledgments

   Many of the colleagues in our companies and participants in the
   ForCES mailing list have provided invaluable input into this work.
   Particular thanks to Jamal Hadi Salim.

9.  References
8.1.

9.1.  Normative References

  1. S. Bradner, "The Internet Standards Process -Revision 3", RFC
     2026,

   [I-D.ietf-forces-mib]
              HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in
              progress), September 2008.

   [I-D.ietf-forces-model]
              Halpern, J. and J. Salim, "ForCES Forwarding Element
              Model", draft-ietf-forces-model-16 (work in progress),
              October 1996.

  2. S. Bradner, "Keywords for use 2008.

   [I-D.ietf-forces-protocol]
              Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,
              Khosravi, H., and W. Wang, "ForCES Protocol
              Specification", draft-ietf-forces-protocol-22 (work in RFCs to Indicate Requirement
     Levels", RFC2119 (BCP), IETF,
              progress), March 1997.

  3. 2009.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3654]  Khosravi, et al., ’’Requirements H. and T. Anderson, "Requirements for Separation
              of IP Control and
     Forwarding”, Forwarding", RFC 3654, November 2003.

  4. L.

   [RFC3746]  Yang, et al., ” ForCES Architectural Framework”, L., Dantu, R., Anderson, T., and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004.

  5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S.
     Blake, "ForCES Forwarding Element Model", Feb. 2005.

  6. A. Doria, et al., ”ForCES Protocol Specification”, draft-ietf-
     forces-protocol-06.txt, December 2005.

8.2.

9.2.  Informative References

  7. A.

   [RFC3015]  Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen,
              B., and J. Segers, "Megaco Protocol Version 1.0",
              RFC 3015, November 2000.

   [RFC3292]  Doria, F. A., Hellstrand, K. F., Sundell, K., and T. Worster, “General
              "General Switch Management Protocol (GSMP) V3”, V3", RFC 3292,
              June 2002.

  8. Andersson et al., "LDP Specification" RFC 3036, January 2001

  9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November
     2000

9. Acknowledgments
   The authors wish to thank Jamal Hadi Salim, Vip Sharma, and many
   others for their invaluable contributions.

10.

Authors' Addresses

   Alan Crouch
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA
   USA

   Phone: +1 503 264 2196
   Email: alan.crouch@intel.com

   Hormuzd Khosravi
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA
   USA

   Phone: 1-503-264-0334
   Email: hormuzd.m.khosravi@intel.com

   Mark Handley
   ICIR
   1947 Center Street, Suite 600
   Berkeley, CA 94708, USA
   Email:  mjh@icsi.berkeley.edu

   Avri Doria
   ETRI
   LTU
   Lulea University of Technology
   Lulea,
   Sweden

   Phone: +46 73 277 1788
   Email: avri@acm.org

   Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Xin-ping Wang
   Huawei
   Beijing
   China

   Phone: +86 10 82836067
   Email: carly.wang@huawei.com

   Kentaro Ogawa
   NTT Corporation
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email: ogawa.kentaro@lab.ntt.co.jp