[Search] [txt|html|xml|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04                                                
Internet Engineering Task Force                            E. Haleplidis
Internet-Draft                                      University of Patras
Intended status: Informational                                  K. Ogawa
Expires: September 5, 2009                               NTT Corporation
                                                                 X. Wang
                                           Huawei Technologies Co., Ltd.
                                                           March 4, 2009


                     ForCES Interoperability Draft
                 draft-ietf-forces-interoperability-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 in 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 September 5, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

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






Haleplidis, et al.      Expires September 5, 2009               [Page 1]


Internet-Draft        ForCES Interoperability Draft           March 2009


Abstract

   This document describes the details of the interoperability test of
   the Forward and Control Element Separation (ForCES) protocol that
   will take place in the University of Patras in Rio, Greece, in the
   fourth week of July 2009.  This informational draft provides
   necessary information, for all parties who wish to participate in the
   interoperability test.


Table of Contents

   1.  Terminology and Conventions  . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  ForCES Protocol  . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  ForCES Model . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Transport mapping layer  . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Testbed architecture . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Local configuration  . . . . . . . . . . . . . . . . . . .  8
     4.2.  Distributed configuration  . . . . . . . . . . . . . . . .  8
   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Scenario 1 - Pre-association Setup . . . . . . . . . . . .  9
     5.2.  Scenario 2 - TML connection  . . . . . . . . . . . . . . .  9
     5.3.  Scenario 3 - TML priority channel connection . . . . . . .  9
     5.4.  Scenario 4 - Association Setup - Association Complete  . . 10
     5.5.  Scenario 5 - CE query  . . . . . . . . . . . . . . . . . . 10
     5.6.  Scenario 6 - Heartbeat monitoring  . . . . . . . . . . . . 10
     5.7.  Scenario 7 - Simple Config Command . . . . . . . . . . . . 11
     5.8.  Scenario 8 - Association Teardown  . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16













Haleplidis, et al.      Expires September 5, 2009               [Page 2]


Internet-Draft        ForCES Interoperability Draft           March 2009


1.  Terminology and Conventions

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].












































Haleplidis, et al.      Expires September 5, 2009               [Page 3]


Internet-Draft        ForCES Interoperability Draft           March 2009


2.  Introduction

   Forwarding and Control Element Separation (ForCES) defines an
   architectural framework and associated protocols to standardize
   information exchange between the control plane and the forwarding
   plane in a ForCES Network Element (ForCES NE).  [RFC3654] has defined
   the ForCES requirements, and [RFC3746] has defined the ForCES
   framework.

2.1.  ForCES Protocol

   The ForCES protocol works in a master-slave mode in which FEs are
   slaves and CEs are masters.  The protocol includes commands for
   transport of Logical Function Block (LFB) configuration information,
   association setup, status, and event notifications, etc.  The reader
   is encouraged to read FE-protocol [I-D.ietf-forces-protocol] for
   further information.

2.2.  ForCES Model

   The FE-MODEL [I-D.ietf-forces-model] presents a formal way to define
   FE Logical Function Blocks (LFBs) using XML.  LFB configuration
   components, capabilities, and associated events are defined when the
   LFB is formally created.  The LFBs within the FE are accordingly
   controlled in a standardized way by the ForCES protocol.

2.3.  Transport mapping layer

   The TML transports the PL messages.  The TML is where the issues of
   how to achieve transport level reliability, congestion control,
   multicast, ordering, etc. are handled.  It is expected that more than
   one TML will be standardized.  The various possible TMLs could vary
   their implementations based on the capabilities of underlying media
   and transport.  However, since each TML is standardized,
   interoperability is guaranteed as long as both endpoints support the
   same TML.  All ForCES Protocol Layer implementations MUST be portable
   across all TMLs.  Although more than one TML may be standardized for
   the ForCES Protocol, for the purposes of the interoperability test,
   the mandated MUST IMPLEMENT SCTP TML [RFC3654] which will be used.












Haleplidis, et al.      Expires September 5, 2009               [Page 4]


Internet-Draft        ForCES Interoperability Draft           March 2009


3.  Definitions

   This document follows the terminology defined by the ForCES
   Requirements in [RFC3654] and by the ForCES framework in [RFC3746].
   The definitions below are repeated below for clarity.

      Control Element (CE) - A logical entity that implements the ForCES
      protocol and uses it to instruct one or more FEs on how to process
      packets.  CEs handle functionality such as the execution of
      control and signaling protocols.

      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.  This process is called FE discovery and may involve
      the CE manager learning the capabilities of available FEs.

      Forwarding Element (FE) - A logical entity that implements the
      ForCES protocol.  FEs use the underlying hardware to provide per-
      packet processing and handling as directed/controlled by one or
      more CEs via the ForCES protocol.

      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.  This process
      is called CE discovery and may involve the FE manager learning the
      capabilities of available CEs.  An FE manager may use anything
      from a static configuration to a pre-association phase protocol
      (see below) to determine which CE(s) to use.  Being a logical
      entity, an FE manager might be physically combined with any of the
      other logical entities such as FEs.

      ForCES Network Element (NE) - An entity composed of one or more
      CEs and one or more FEs.  To entities outside an NE, the NE
      represents a single point of management.  Similarly, an NE usually
      hides its internal organization from external entities.

      LFB (Logical Function Block) - The basic building block that is
      operated on by the ForCES protocol.  The LFB is a well defined,
      logically separable functional block that resides in an FE and is
      controlled by the CE via ForCES protocol.  The LFB may reside at
      the FE's datapath and process packets or may be purely an FE
      control or configuration entity that is operated on by the CE.
      Note that the LFB is a functionally accurate abstraction of the
      FE's processing capabilities, but not a hardware-accurate
      representation of the FE implementation.





Haleplidis, et al.      Expires September 5, 2009               [Page 5]


Internet-Draft        ForCES Interoperability Draft           March 2009


      FE Topology - A representation of how the multiple FEs within a
      single NE are interconnected.  Sometimes this is called inter-FE
      topology, to be distinguished from intra-FE topology (i.e., LFB
      topology).

      LFB Class and LFB Instance - LFBs are categorized by LFB Classes.
      An LFB Instance represents an LFB Class (or Type) existence.
      There may be multiple instances of the same LFB Class (or Type) in
      an FE.  An LFB Class is represented by an LFB Class ID, and an LFB
      Instance is represented by an LFB Instance ID.  As a result, an
      LFB Class ID associated with an LFB Instance ID uniquely specifies
      an LFB existence.

      LFB Metadata - Metadata is used to communicate per-packet state
      from one LFB to another, but is not sent across the network.  The
      FE model defines how such metadata is identified, produced and
      consumed by the LFBs.  It defines the functionality but not how
      metadata is encoded within an implementation.

      LFB Attribute - Operational parameters of the LFBs that must be
      visible to the CEs are conceptualized in the FE model as the LFB
      attributes.  The LFB attributes include, for example, flags,
      single parameter arguments, complex arguments, and tables that the
      CE can read and/or write via the ForCES protocol (see below).

      LFB Topology - Representation of how the LFB instances are
      logically interconnected and placed along the datapath within one
      FE.  Sometimes it is also called intra-FE topology, to be
      distinguished from inter-FE topology.

      Pre-association Phase - The period of time during which an FE
      Manager and a CE Manager are determining which FE(s) and CE(s)
      should be part of the same network element.

      Post-association Phase - The period of time during which an FE
      knows which CE is to control it and vice versa.  This includes the
      time during which the CE and FE are establishing communication
      with one another.

      ForCES Protocol - While there may be multiple protocols used
      within the overall ForCES architecture, the term "ForCES protocol"
      and "protocol" refer to the Fp reference points in the ForCES
      Framework in [RFC3746].  This protocol does not apply to CE-to-CE
      communication, FE-to-FE communication, or to communication between
      FE and CE managers.  Basically, the ForCES protocol works in a
      master- slave mode in which FEs are slaves and CEs are masters.
      This document defines the specifications for this ForCES protocol.




Haleplidis, et al.      Expires September 5, 2009               [Page 6]


Internet-Draft        ForCES Interoperability Draft           March 2009


      ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
      ForCES protocol architecture that uses the capabilities of
      existing transport protocols to specifically address protocol
      message transportation issues, such as how the protocol messages
      are mapped to different transport media (like TCP, IP, ATM,
      Ethernet, etc), and how to achieve and implement reliability,
      multicast, ordering, etc.  The ForCES TML specifications are
      detailed in separate ForCES documents, one for each TML.











































Haleplidis, et al.      Expires September 5, 2009               [Page 7]


Internet-Draft        ForCES Interoperability Draft           March 2009


4.  Testbed architecture

   Most FEs and CEs should be located locally at the University of
   Patras premises.  But if some parties would like to participate but
   cannot attend the interoperability test locally a connection over the
   internet MAY be created.

   The actual test will take place between FEs and CEs of different
   implementors with different permutations.

4.1.  Local configuration

   Hardware/Software (CEs and FEs) that will be located within the
   University of Patras premises, will be connected together using
   switches and hubs.  For each permutation there would be a different
   subnet ranging starting from 192.168.1.xxx to 192.168.255.xxx to
   distinguish them.

   For each subnet there will be a machine with IP 192.168.xxx.2 which
   will act as a network monitor using a network analyzer that should be
   able to show the packets that are traversing the network.The IPs of
   CEs and FEs will range from 192.168.xxx.3 to 192.168.xxx.254

   This will help minimize packet interference with other machines and
   make the testing and the validation easier

4.2.  Distributed configuration

   For parties that cannot participate locally there are two current
   propositions:

   1.  A SCTP over IPsec (VPN) case, where CE and FE are part of a VPN.

   2.  SCTP over IP with a firewall that will allow only the CEs and FEs
       IPs.

   A number of public IPs will be provided by the University of Patras
   will be provided for such a case.













Haleplidis, et al.      Expires September 5, 2009               [Page 8]


Internet-Draft        ForCES Interoperability Draft           March 2009


5.  Scenarios

   All protocol messages of each scenario will be monitored using a
   protocol network analyzer to test validity.

5.1.  Scenario 1 - Pre-association Setup

   While the Pre-association setup is not in the ForCES current scope it
   is an essential step before CEs and FEs communicate.  As the first
   part in a succesfull CE-FE connection the participating CEs and FEs
   should be able to be configured.  In the Pre-association Phase the
   following configuration items MUST be setup regarding the CEs:

   o  Which FE IDs should they be connected

   o  The IP of the corresponsing FEs

   In the Pre-association Phase the following configuration items MUST
   be setup regarding the FEs:

   o  Which CE IDs should they be connected

   o  The IP of the corresponsing CEs

   Once each element is configured, Scenario 1 is successfull.

5.2.  Scenario 2 - TML connection

   For the current interoperability test, the SCTP will be used as TML.
   The TML connection with the associating element is needed for the
   scenario 2 to be successfull.

5.3.  Scenario 3 - TML priority channel connection

   The SCTP-TML draft [I-D.ietf-forces-sctptml] defines 3 priority
   channels, with specific ports:

   o  High priority - Port number: 6700

   o  Medium priority - Port number: 6701

   o  Lower priority - Port number: 6702

   Once these channels have been established with each associated
   element, will the Scenario 3 be successfull.






Haleplidis, et al.      Expires September 5, 2009               [Page 9]


Internet-Draft        ForCES Interoperability Draft           March 2009


5.4.  Scenario 4 - Association Setup - Association Complete

   Once the Pre-association phase has been complete in the previous 3
   scenarios, CEs and FEs are ready to communicate using the ForCES
   protocol, and enter the Association Setup stage.  In this stage the
   FEs attempts to join the NE.  The following ForCES protocol messages
   will be exchanged for each CE-FE pair:

   o  Association Setup Message (from FE to CE)

   o  Association Setup Response Message (from CE to FE)

   Once the associations has been initialized scenario 4 will have been
   successfull.

5.5.  Scenario 5 - CE query

   Once the Association Phase stage has been complete, the FEs and CEs
   will enter the Established stage.  In this stage the FE is
   continuously updated or queried.  The CE should query the FE a
   specific value from the FE Object LFB and from the FE Protocol LFB.
   An example from the FE Protocol LFB is the HeartBeat Timer (FEHI) and
   from the FE Object LFB is the State of the LFB (FEState)

   The following ForCES protocol messages will be exchanged:

   o  Query Message

   o  Query Response Message

5.6.  Scenario 6 - Heartbeat monitoring

   The Heartbeat (HB) Message is used for one ForCES element (FE or CE)
   to asynchronously notify one or more other ForCES elements in the
   same ForCES NE on its liveness.  The default configuration of the
   Heartbeat Policy of the FE is set to 0 which means, that the FE
   should not generate any Heartbeat messages. the CE is responsible for
   checking FE liveness by setting the PL header ACK flag of the message
   it sends to AlwaysACK.  In this Scenario the CE should send a
   Heartbeat message with the ACK flag set to AlwaysACK and the FE
   should respond.

   The following ForCES protocol messages will be exchanged:

   o  Heartbeat Message






Haleplidis, et al.      Expires September 5, 2009              [Page 10]


Internet-Draft        ForCES Interoperability Draft           March 2009


5.7.  Scenario 7 - Simple Config Command

   A config message is sent by the CE to the FE to configure LFB
   components in the FE.  A simple config command easily visilble and
   metered would be to change the Heartbeat configuration.  This will be
   done in two steps:

   1.  Change the FE Heartbeat Policy (FEHBPolicy) to value 1, to force
       the FE to send heartbeats.

   2.  After some heartbeats from the FE, the FE Heartbeat Interval
       (FEHI) will be changed.

   The following ForCES protocol messages will be exchanged:

   o  Config Message

   o  Config Response Message

5.8.  Scenario 8 - Association Teardown

   In the end, the association must be terminated.  There are two
   scenarios by which the association maybe terminated:

   1.  By stopping heartbeats from a FE or a CE.

   2.  By externally shutting down/rebooting a FE or a CE.

   Both scenarios may be tested in the interoperability test.

   The following ForCES protocol messages will be exchanged:

   o  Association Teardown Message


















Haleplidis, et al.      Expires September 5, 2009              [Page 11]


Internet-Draft        ForCES Interoperability Draft           March 2009


6.  Acknowledgements

   TBA
















































Haleplidis, et al.      Expires September 5, 2009              [Page 12]


Internet-Draft        ForCES Interoperability Draft           March 2009


7.  IANA Considerations

   This memo includes no request to IANA.
















































Haleplidis, et al.      Expires September 5, 2009              [Page 13]


Internet-Draft        ForCES Interoperability Draft           March 2009


8.  Security Considerations

   We should consider security issues if we have connections when there
   are associations between CEs and FEs over the internet.  Perhaps SCTP
   over IPsec may be used.

   TBA.












































Haleplidis, et al.      Expires September 5, 2009              [Page 14]


Internet-Draft        ForCES Interoperability Draft           March 2009


9.  References

9.1.  Normative References

   [I-D.ietf-forces-model]
              Halpern, J. and J. Salim, "ForCES Forwarding Element
              Model", draft-ietf-forces-model-16 (work in progress),
              October 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-21 (work in
              progress), February 2009.

   [I-D.ietf-forces-sctptml]
              Salim, J. and K. Ogawa, "SCTP based TML (Transport Mapping
              Layer) for ForCES protocol", draft-ietf-forces-sctptml-02
              (work in progress), January 2009.

9.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

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

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.









Haleplidis, et al.      Expires September 5, 2009              [Page 15]


Internet-Draft        ForCES Interoperability Draft           March 2009


Authors' Addresses

   Evangelos Haleplidis
   University of Patras
   Patras,
   Greece

   Email: ehalep@ece.upatras.gr


   Kentaro Ogawa
   NTT Corporation
   Tokyo,
   Japan

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


   Xin-ping Wang
   Huawei Technologies Co., Ltd.
   China

   Email: carly.wang@huawei.com




























Haleplidis, et al.      Expires September 5, 2009              [Page 16]