PCE Working Group                                                  Q. Wu
Internet-Draft                                                  D. Dhody
Intended status: Standards Track                                  Huawei
Expires: January 1, September 8, 2016                                  M. Boucadair
                                                            C. Jacquenet
                                                          France Telecom
                                                                  Orange
                                                             J. Tantsura
                                                                Ericsson
                                                           June 30, 2015
                                                           March 7, 2016

          PCEP Extensions for traffic steering support in Service Function Chaining
                  draft-wu-pce-traffic-steering-sfc-07 (SFC)
                  draft-wu-pce-traffic-steering-sfc-08

Abstract

   This document provides an overview of the usage of Path Computation
   Element (PCE) with to dynamically structure service function chains.
   Service Function Chaining (SFC); which (SFC) is
   described as a technique that is meant to
   facilitate the definition and instantiation dynamic enforcement of differentiated traffic
   forwarding policies within a domain.  Service function chains are
   composed of an ordered set of
   such service functions elementary Service Functions (such as
   firewalls, load balancers), and balancers) that need to be invoked according to the
   subsequent "steering"
   design of a given service.  Corresponding traffic flows through those service
   functions. is thus forwarded
   along a Service Function Path (SFP) that can be computed by means of
   PCE.

   This document specifies extensions to the Path Computation Element
   Protocol (PCEP) that allow a stateful PCE to compute and instantiate
   Service Function Paths (SFP). Paths.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 1, September 8, 2016.

Copyright Notice

   Copyright (c) 2015 2016 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Service Function Paths and PCE  . . . . . . . . . . . . . . .   3   4
   4.  Overview of PCEP Operation in SFC-enabled SFC-Enabled Networks  . . . . .   5
     4.1.  SFP Instantiation . . . . . . . . . . . . . . . . . . . .   6
     4.2.  SFP Withdrawal  . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  SFP Delegation and Cleanup  . . . . . . . . . . . . . . .   6
     4.4.  SFP State Synchronization . . . . . . . . . . . . . . . .   6
     4.5.  SFP Update and Report . . . . . . . . . . . . . . . . . .   6
   5.  Object Formats  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  The OPEN Object . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  The LSP Object  . . . . . . . . . . . . . . . . . . . . .   7
       5.2.1.  SFP Identifiers TLV . . . . . . . . . . . . . . . . .   8
   6.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   9
   7.  SFP signaling Signaling and forwarding consideration Forwarding Considerations . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Service chaining Function Chaining (SFC) enables the creation of composite
   services that consist of an ordered set of Service Functions (SF)
   that must be applied to packets and/or frames and/or flows selected
   as a result of service-inferred traffic classification as described
   in [I-D.ietf-sfc-architecture] and
   referred to as Service Function Chain (SFC). [RFC7665].  A Service Function Path (SFP) is the instantiation of a SFC in the network. path along which
   traffic that is bound to a specific service function chain will be
   forwarded.  Packets typically follow a Service Function Path from a
   classifier through the requisite Service Functions (SF) and that need to be invoked
   according to the SFC instructions.  Forwarding decisions are made by
   Service Function Forwarders (SFF). (SFF) according to such instructions.

   [RFC5440] describes the Path Computation Element Protocol (PCEP) as
   the communication between protocol used by a Path Computation Client (PCC) and a Path
   Control Element (PCE), or between PCE and PCE, (PCE) to exchange information, thereby enabling the
   computation of Multiprotocol Label Switching (MPLS) for Traffic
   Engineering Label Switched Path (TE LSP). LSP), in particular.

   [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable a
   stateful control of MPLS TE LSPs.  [I-D.ietf-pce-pce-initiated-lsp]
   provides the fundamental extensions needed for stateful PCE-initiated LSP
   instantiation.

   This document specifies extensions to the PCEP extensions that allow a stateful PCE to
   compute and instantiate traffic-engineered Service Function Paths
   (SFP).

2.  Conventions used in this document

   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 [RFC2119].

   The following terminologies are used in this document:

   This document makes use of these acronyms:

   PCC:  Path Computation Client.

   PCE:  Path Computation Element.

   PCEP:  Path Computation Element Protocol.

   PDP:  Policy Decision Point.

   SF:  Service Function.

   SFC:  Service Function Chain.

   SFP:  Service Function Path.

   RSP:  Rendered Service Path.

   SFF:  Service Forwarder Function. Function Forwarder.

   UNI:  User-Network Interface.

3.  Service Function Paths and PCE

   Services

   Service function chains are constructed as a sequence of SFs that represent an SFC, SFs, where a
   SF can be a virtual instance virtualized or be embedded in a physical network element, and one element.  One
   or more several SFs may be supported by the same physical network element.
   A SFC creates an abstracted view of a service and specifies the set
   of required SFs as well as the order in which they must be executed.

   When an SFC is instantiated into the network created, it is necessary to select the specific
   instances of SFs that will be used, and to create
   the used.  A service function path for that
   SFC using will then be established (notion of rendered service path) or can
   be precomputed, based upon the sequence of SFs that need to be
   invoked by the corresponding traffic, i.e., the traffic that is bound
   to the corresponding SFC.  Note that a SF network locators. instance can be serviced by
   one or multiple SFFs.  One or multiple SF instances can be serviced
   by one SFF.  Thus, the instantiation of a an SFC results in the
   establishment of a Service Function Path, either in a la hop-by-hop through the ordered
   sequence of SF functions,
   fashion, or in a pre-computed, traffic-engineered
   fashion. by means of traffic-engineering capabilities.  In other words, the
   latter case, the SFP is precomputed, i.e., an SFP is the an instantiation
   of the defined SFC as described in [I-D.ietf-sfc-architecture]. [RFC7665].

   The selection computation, the selection, and the establishment of a traffic-
   engineered SFP can be based on rely upon a set of policy attributes (service-specific) policies
   (forwarding and routing, QoS, security, etc., or a combination
   thereof), ranging from simple to more elaborate selection criteria
   and the use of stateful
   thereof).  Stateful PCE with extensions to PCEP are one such way
   to achieve this.

   Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of
   extensions to appropriate SFC-aware PCEP to enable stateful control of TE LSPs.
   [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations
   and extensions needed for stateful PCE-initiated LSP instantiation.
   This document specifies extensions that allow a stateful PCE
   can be used to compute and instantiate Service Function Paths (SFP) via PCEP. traffic-engineered SFPs.

                 SFC Control Element
                 +------------------------+
                 |           stateful PCE |
                 |  +-------+  +-------+  |
                 |  |Policy |  | TE-DB |  |    +-------+
                 |  +-------+  +-------+  |    |  SFC  |
      +----------|      +-------------+   |<---|control|   |
      |SFP       |      |LSP-DB/SFP-DB|   |    | plane |
      |Instan-   |      +-------------+   |    +-------+
      |tiation   +------------------------+
      |            +-----+ +-----+          +-----+
      |            |SF-1 | |SF-2 |          |SF-3 |
      |            |     | |     |          |     |
      |            +---+-+ +-+---+          +--+--+
      |                |     |                 |
      |               ++-----++           +----+--+
      V               |       |           |       |
   +-----+  Signaling |       | Signaling |       | Signaling
   | SF SFC |----------->| SFF-1 | --------->| SFF-2 |----------->
   Classifier         |       |           |       |
   |Node
   |     |            |       |           |       |
   +-----+            +-------+           +-------+

                   Figure 1: PCE based PCE-based SFP instantiation

   The SFC Control plane components are Element [I-D.ietf-sfc-control-plane] is responsible
   for maintaining SFC
   Policy Tables defining service instructions to bind a flow to a service
   function chain and enforcing forward such flow along the corresponding SFP.  It
   is also responsible for defining the appropriate policies in SF Classifier (traffic
   classification, forwarding and routing, etc.) that will be enforced
   by SFC Classifiers and SFF Nodes as described in
   [I-D.ietf-sfc-architecture][I-D.ww-sfc-control-plane]. [RFC7665].  The SFC
   Control plane component Element can be seen as a policy Policy Decision point
   (PDP,[RFC5394]). Point (PDP,
   [RFC5394]).  Such PDP can then operates operate a stateful PCE and its
   instantiation mechanism to compute compute,
   select and instantiate establish Service Function
   Paths (SFP). Paths.  The PCE maybe co-located may be co-
   located with the SFC Control plane
   component element or enabled in an external
   entity.

4.  Overview of PCEP Operation in SFC-enabled SFC-Enabled Networks

   A PCEP speaker indicates its ability to support PCE provisioned
   dynamic PCE-computed SFP
   paths during the PCEP Initialization phase via a mechanism described
   in Section 5.1.  A PCE can may initiate SFPs only for PCCs that
   advertised this capability and capability; a PCC will follow follows the procedures described in
   this document only on for sessions where the PCE advertised this
   capability.

   As per section Section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends
   a Path Computation LSP Initiate Request (PCInitiate) message to the
   PCC to instantiate or delete a LSP.  The Explicit Route Object (ERO)
   can be
   is used to encode either a full sequence of SF functions instances or a
   combination
   specific sequence of SFs and SFFs and SFs to establish a an SFP.  If the said
   SFFs and SFs can be are identified with an IP address, the IP sub-object can
   be used as a SF/SFF identification means.  This document makes no
   change to the PCInitiate message format but extends LSP objects
   described in Section 5.2.

   Editor-Note:

   Editor's note: In case a PCE-Initiated Signaling signaling mechanism is used to
   setup
   set up the service function path, then does the classifier / PCE-
   Initiated signaling protocol needs need to understand if the IP address is
   for SFF or SF or the signaling protocol is only used to signal IP
   address
   addresses for SFs?

4.1.  SFP Instantiation

   The Instantiation operation instantiation of a SFP is the same as defined in
   section 5.3[I-D.ietf-pce-pce-initiated-lsp].  Rules Section 5.3 of
   [I-D.ietf-pce-pce-initiated-lsp].  Rules for processing and error
   codes remain unchanged.

4.2.  SFP Withdrawal

   The withdrawal operation of a an SFP is the same as defined in section Section 5.4 of [I-D.ietf-pce-pce-initiated-lsp] :
   [I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate
   Message with an LSP object carrying the PLSP-ID of the SFP and the
   SFP Identifier to be removed and removed, as well as an SRP object with the R
   flag set (LSP-REMOVE as per section Section 5.2 of
   [I-D.ietf-pce-pce-initiated-lsp]).  Rules of for processing and error
   codes remain unchanged.

4.3.  SFP Delegation and Cleanup

   SFP delegation and cleanup operations are similar to those defined in
   section
   Section 6 of [I-D.ietf-pce-pce-initiated-lsp].  Rules of for processing
   and error codes remains remain unchanged.

4.4.  SFP State Synchronization

   State Synchronization operations described in Section 5.4 of
   [I-D.ietf-pce-stateful-pce]can
   [I-D.ietf-pce-stateful-pce] can be applied for to SFP state maintenance
   as well.

4.5.  SFP Update and Report

   A PCE can send an SFP Update request to a PCC to update one or more
   attributes of an SFP and to re-signal the SFP with the updated
   attributes.  A PCC can send an SFP state report to a PCE, and which
   contains the SFP State information.  The mechanism is described in
   [I-D.ietf-pce-stateful-pce] and can be applied for to SFPs as well.

5.  Object Formats

5.1.  The OPEN Object

   This document defines a new

   The optional TLV shown in Figure 2 is defined for use in the OPEN
   Object to indicate the PCEP speaker's Service function Function Chaining
   capability.

   The SFC-PCE-CAPABILITY TLV is an optional TLV for use to be carried in the
   OPEN Object to advertise the SFC capability during the PCEP session.  The
   format of the SFC-PCE-CAPABILITY TLV is shown in the
   followingFigure 2 :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type=TBD           |            length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       SFC-PCE-CAPABILITY TLV Format

   The code point for the TLV type is to be defined by IANA. IANA (see
   Section 9).  The TLV length is 4 octets.

   The value is TBD.

   As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the
   capability of instantiating PCE-initiated LSPs via the Stateful PCE
   Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) conveyed carried in an Open
   message.  The inclusion of the SFC-PCE-CAPABILITY TLV in an OPEN
   object indicates that the sender is SFC-capable.  Both mechanisms
   indicate the SFP instantiation capability of the PCEP speaker.

5.2.  The LSP Object

   The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and
   included here for reference (Figure 3).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                PLSP-ID                | Flags |F|C|  O|A|R|S|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        TLVs                                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             LSP Object Format

   A new flag, called the SFC (F) flag, flag (F-bit), is introduced.  The F Flag F-bit
   set to 1 "1" indicates that this LSP is actually an SFP.  The C flag
   will also be set to indicate it was created via a PCInitiate message.

5.2.1.  SFP Identifiers TLV

   The SFP Identifiers TLV MUST be included in the LSP object for
   Service Function Paths (SFP). SFPs.
   The SFP Identifier TLV is used by the classifier to enable SFP selection for select the traffic,i.e.,direct SFP
   along which some traffic will be forwarded, according to specific SFP[I-D.ietf-sfc-architecture]. the traffic
   classification rules applied by the classifier [RFC7665].  The SFP
   Identifier carried in is part of the SFC encapsulation can be further metadata carried in packets and is used
   by the SFF to select invoke service functions and next SFF,e.g., enable a packet
   that repeatedly arrives at the same SFF to get the correct services
   provided each time it arrives, and to go to identify the correct next SFF each
   time it arrives. SFF.

   The format of the SFP Identifier TLV is shown in the following figure. Figure 4.

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Service Path ID                      | Service Index |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Service path Path ID (SPI): 24 bits
      Service index Index (SI): 8 bits

                                 Figure 4

   SPI: identifies a service path.  The same ID is used by the
   participating nodes for path setup/selection.  An administrator can
   use the SPI for reporting and troubleshooting packets along a
   specific path.  SPI along with PLSP-ID is used in by PCEP to identify
   the Service Path.

   SI: provides location within the service path.

6.  Backward Compatibility

   The SFP instantiation capability defined as a PCEP protocol extensions described extension and
   documented in this document draft MUST NOT be used if PCCs or the PCE did not
   advertise its their stateful SFP instantiation stateful capability, as per
   Section capability,Section 5.1.
   If this is not the case and stateful operations on SFPs are
   attempted, then a PCErr message with error-type 19 (Invalid
   Operation) and error-value TBD needs to be generated.

   [Editor Note:

   [Editor's note: more information on exact error value is needed]

7.  SFP signaling Signaling and forwarding consideration Forwarding Considerations

   The SFP instantiation mechanism described in this document is not
   tightly coupled to any SFP signaling mechanism.  For example,SR-based example, Generic
   SFC Encapsulation [I-D.ietf-sfc-nsh] can be used together with the
   mechanism described in this document to enable SFP forwarding.  SR-
   based approach [I-D.ietf-pce-segment-routing] can utilize also use the
   mechanism described here and does not need any other specific
   protocol extensions.  Generic SFC Encapsulation [I-D.quinn-sfc-nsh] can also
   be used together with the mechanism described here to enable SFP
   forwarding.

8.  Security Considerations

   The security considerations described in [RFC5440] and
   [I-D.ietf-pce-pce-initiated-lsp] are applicable to this
   specification.  No  This document does not raise any additional security measure is required.
   issue.

9.  IANA Considerations

   IANA is requested to allocate a new code point in the PCEP TLV Type
   Indicators registry, as follows:

      Value   Meaning                      Reference
      ------- ---------------------------- --------------
      TBD     SFC-PCE-CAPABILITY           This document

10.  Acknowledgements

   Many thanks to Ron Parker, Hao Wang,Dave Dolson,Jing Huang,Joel Wang, Dave Dolson, Jing Huang, and
   Joel M.  Halpern for the discussion in formulating the content for
   the draft. document.

11.  References
11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-11
              pce-13 (work in progress), April December 2015.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-04 draft-ietf-pce-pce-initiated-lsp-05 (work in
              progress), April October 2015.

11.2.  Informative References

   [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
              for Policy-based Admission Control", RFC 2753,
              DOI 10.17487/RFC2753, January
              2000. 2000,
              <http://www.rfc-editor.org/info/rfc2753>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC 5394,
              DOI 10.17487/RFC5394, December 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440, March
              2009.

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-09 (work
              in progress), June 2015.

   [I-D.ww-sfc-control-plane] 2008,
              <http://www.rfc-editor.org/info/rfc5394>.

   [I-D.ietf-sfc-control-plane]
              Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
              Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,
              Halpern, J., Reddy, T., and P. Patil, "Service Function
              Chaining (SFC) Control Plane Components & Requirements", draft-ww-
              sfc-control-plane-06
              draft-ietf-sfc-control-plane-03 (work in progress), June 2015.
              January 2016.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
              Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
              "PCEP Extensions for Segment Routing", draft-ietf-pce-
              segment-routing-05
              segment-routing-06 (work in progress), May August 2015.

   [I-D.quinn-sfc-nsh]

   [I-D.ietf-sfc-nsh]
              Quinn, P., Guichard, J., Surendra, S., Smith, M.,
              Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,
              Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
              D., Garg, P., McConnell, B., Wright, C., P. and K. Kevin, U. Elzur, "Network Service Header", draft-quinn-sfc-nsh-07 draft-
              ietf-sfc-nsh-02 (work in progress), February 2015. January 2016.

Authors' Addresses

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   EMail: sunseawq@huawei.com bill.wu@huawei.com

   Dhruv Dhody
   Huawei
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: dhruv.ietf@gmail.com

   Mohamed Boucadair
   France Telecom
   Orange
   Rennes 35000
   France

   EMail: mohamed.boucadair@orange.com

   Christian Jacquenet
   France Telecom
   Orange
   Rennes 35000
   France

   EMail: christian.jacquenet@orange.com
   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   US

   EMail: Jeff.Tantsura@ericsson.com