[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
PCE Working Group                                     M. Boucadair (Ed.)
Internet Draft                                           P. Morand (Ed.)
                                                      France Telecom R&D
Document: draft-boucadair-pce-discovery-01.txt                  May 2005
Category: Standards Track


     Path Computation Service discovery via Border Gateway Protocol
                 < draft-boucadair-pce-discovery-01.txt >



Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667 [RFC3667].  By submitting this Internet-
   Draft, each author represents that any 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 become aware will be disclosed, in
   accordance with RFC 3668 [RFC3668].

   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 November 2005.


Abstract

   This draft describes a simple mechanism that ease discovery of remote
   Autonomous   Systems   (AS)   supporting   inter-domain   MPLS-based
   constrained tunnels service (this service is also denoted by Path
   Computation Service (PCSv)) thanks to the use of Path Computation
   Elements (PCEs). Remote ASs could be managed by a single or distinct
   Internet Network Providers (INP).
   Particularly, this draft describes how Border Gateway Protocol (BGP)
   is used to announce Path Computation Service unique identifiers

Boucadair (Ed.)  Standards Track- Expires November 2005         [Page 1]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

   across the Internet in order for other PCEs to be able to discover a
   path towards every AS supporting this Path Computation Service.


Table of Contents


   1.      Contributors................................................2
   2.      Changes since last version:.................................2
   3.      Terminology.................................................2
   4.      Introduction................................................3
   4.1.    General.....................................................3
   4.2.    Structure of the draft......................................4
   5.      Conventions used in this document...........................4
   6.      PCE discovery within a single domain........................5
   7.      Overview of the service approach............................5
   8.      Service Advertisement and Discovery.........................6
   9.      Why PCE discovery is needed.................................7
   10.     Solution for PCSv discovery.................................7
   11.     IANA Considerations.........................................8
   12.     Security Considerations.....................................8
   13.     References..................................................9
   14.     Acknowledgments.............................................9
   15.     Author's Addresses.........................................10


1.   Contributors

   o Hamid Asgari (Thales Research and Technology)
   o Panagiotis Georgatsos (Algonet)
   o David Griffin (University College London)
   o Micheal Howarth (University of Surrey)
   o Noel Cantenot (France Telecom)


2.   Changes since last version:

   The main changes occurred in this version are:
   o Rewording of several sections of the draft


3.   Terminology

   This memo makes use of the following terms:

     o Path Computation Element (PCE): an entity that is responsible
        for computing/finding inter/intra domain paths for establishing
        LSPs. This entity can simultaneously act as client and a server.
        Several PCEs could be deployed in a given AS.



Boucadair (Ed.) Standards Track - Expires November 2005        [Page 2]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

     o Path Computation Client (PCC): a PCE acting as a client. This
        entity is responsible for issuing path computation requests that
        fulfill the Service Management constraints for the establishment
        of inter/intra domain LSPs.

     o Path Computation Server (PCS): a PCE acting as a server. This
        entity is responsible for handling path computation requests in
        order to satisfy PCC constraints.

     o High-level service: is the service using a PCE-based system as
        an underlying infrastructure (an inter-domain QoS VPNs service
        for instance)

     o High-level service customer: is a customer that subscribes to a
        High-level service.

     o pSLS: A provider SLS is an SLS established between two Internet
        Network Providers (INP) with the purpose of extending the
        geographical span of their service offers.

     o SLS Management: This management entity is responsible for SLS-
        related activites, including  pSLS ordering (i.e establishing
        contracts between peers) and SLS invocation (i.e committing
        resources before traffic can be admitted)

     o q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into
        account  QoS  information  as  input  for  its  route  selection
        process.

     o Domain: within this draft it denotes an Autonomous system.


4.   Introduction

4.1.     General

   Recently, several proposals describing the use of a Path Computation
   Element (PCE) as additional element to existent IP network entities
   have been submitted to the IETF. The main objective of introducing a
   PCE  element  is  to  ease  computation  of  constrained  paths  in
   sophisticated schemes like inter-domain (both in intra-provider or
   inter-provider) and then driving the establishment of inter-domain
   LSPs.

   A framework for establishing and controlling Multi-Protocol Label
   Switching  Protocol  (MPLS)  and  Generalized  MPLS  (GMPLS)  Label
   Switching Paths (LSPs) in multi-domain networks has been defined in
   [CCAMP-FWRK]. The notion of domain in this framework draft encloses
   both Interior Gateway Protocol (IGP) areas and Autonomous System (AS)
   contrary to the current draft that restricts the notion of domain to
   a single AS.

Boucadair (Ed.) Standards Track - Expires November 2005        [Page 3]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol


   Another draft that proposes a solution to compute inter-domain
   constrained paths has been submitted to the IETF [INTERAS-PCE]. This
   draft  takes  into  account  the  inter-provider  specific  service
   considerations. In addition, the draft [INTERAS-PCP] describes a new
   protocol allowing communication between two PCEs located in different
   domains in order to compute inter-domain paths satisfying a set of
   constraints.

   All aforementioned drafts require a Path Computation Service (PCSv)
   discovery function that allows discovery of remote ASs supporting
   this  type  of  service  (the  path  computation  service  could  be
   implemented by one or several PCE elements) together with theirs
   associated                     capabilities                     like
   QoS capabilities, inter-domain bandwidth, reachable IP prefixes, type
   of links, etc. Discovery of such capabilities could also be passive
   and be restricted to a simple service advertisement (like web-pages).
   PCSv locations and associated capabilities discovery depends on
   providers search. We will refer to this method as passive discovery
   method.

   It  is  evident  that  passive  method  allows  finding  remote  PCSv
   locations and their associated capabilities, but this information is
   not usable alone within a distributed PCE architecture, when a set of
   end-to-end constraints must be satisfied. Therefore, computation of
   end-to-end  constraints  must  be  achieved  based  on  advertised
   individual PCE capabilities. The knowledge of the PCE path is then
   mandatory in order to deduce the end-to-end capabilities.

   In this draft, we present a simple method that allows discovery of
   remote PCSv with their associated capabilities. This method will also
   help the PCE decision-making process to choose the next PCE to
   contact in order to optimize paths towards a given destination.


4.2.     Structure of the draft

   This draft is structured as follows:

      o Section 5 gives an overview of the service approach;
      o Section 6 argues on the need of PCSv discovery functions;
      o Section 7 presents a solution proposal for PCSv discovery.


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



Boucadair (Ed.) Standards Track - Expires November 2005        [Page 4]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

6.   PCE discovery within a single domain

   Within a single domain, discovery of PCSv location and capabilities
   could be achieved for instance thanks to the activation of the
   Service Location Protocol (SLP, [RFC2608]). This protocol allows
   discovery   of   activated   services   that   uses   client/service
   architecture. SLP defines the same framework for all services.

   In order to use SLP as a means to discover PCSvs, a PCE Service Type
   Template SHOULD be defined.


7.   Overview of the service approach

   Neighboring domains establish pSLSs (a pSLS is an enhanced SLS
   agreement between two providers. SLS template is defined in [SLS])
   between  them  in  order  to  have  appropriate  rights  to  request
   establishment of LSPs. An inter-domain routing protocol runs between
   the domains (for instance Border Gateway Protocol (BGP, [RFC1771])).
   The LSP creation request is propagated downstream to appropriate
   PCEs. The requests include the AS's ASBR and the tail-end address of
   the LSP. This procedure is repeated until the request reaches the
   destination PCE.

              +--------High Level Service Agreement--------+
              |                                            |
              v                                            v
        <----AS1----->        <----AS2----->         <----AS3----->
        '            '        '            '         '            '
        '            '<-pSLS->'            '<- pSLS->'            '
        '            '        '            '         '            '
        +------------+        +------------+         +------------+
        |    PCE     |        |    PCE     |         |    PCE     |
        |            |        |            |         |            |
        |  +------+  |        |  +------+  |         |  +------+  |
        |  | PCC  |  |        |  | PCC  |  |         |  | PCC  |  |
        |  |      |<-|--\     |  |      |<-|--\      |  |      |  |
        |  +--/\--+  |  |     |  +--/\--+  |  |      |  +--/\--+  |
        |     ||     |  |PCP  |     ||     |  |PCP   |     ||     |
        |     ||     |  |     |     ||     |  |      |     ||     |
        |  +--\/--+  |  |     |  +--\/--+  |  |      |  +--\/--+  |
        |  | PCS  |  |  \-----|->| PCS  |  |  \------|->| PCS  |  |
        |  |      |  |        |  |      |  |         |  |      |  |
        |  +------+  |        |  +------+  |         |  +------+  |
        +------------+        +------------+         +------------+

                        Figure 1: Service Overview


   After  authenticating  the  identity  of  LSP  originating  PCE,  the
   destination PCE send a reply message back to the downstream domain's

Boucadair (Ed.) Standards Track - Expires November 2005        [Page 5]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

   PCE  accepting  the  request  and  include  the  LSP  loose  path
   (destination, ASBR) addresses in the message. The next downstream
   domain's PCE does the same and adds its own relevant ASBR addresses
   to the loose path. The originating PCE inserts its intra-domain path
   and  then  initializes  an  RSVP  reservation  request  for  LSP
   establishment using the returned loose path.

   At the service/application level (in order to differentiate this
   service from extending scope of IP connectivity service, we will
   denote it as high level service), when originating AS wants to
   establish an LSP to a destination in a remote ASs, there MUST be an
   agreement between the two ASs.


8.   Service Advertisement and Discovery

   Within  this  draft,  we  make  a  difference  between  the  Service
   Advertisement and Discovery (SAD) and PCSv discovery function. SAD is
   a function that is achieved before establishing a service agreement
   between  two  peers.  The  SAD  operation  consists  mainly  at
   advertising/learning  from/to  the  rest  of  the  Internet  the
   capabilities supported by a given AS in term of offered services
   (like Inter-domain LSP establishment service). PCSv advertisement is
   conditioned by the existence of a pSLS between two peers.

                AS1            '                AS2
                               '
   +----------------------+    '
   |Service Advertisement |<---'-------------------\
   +----------------------+    '                   |
                               '                   |
                                        +----------v-----------+
                                        |   Service Discovery  |
                                        +----------------------+
                               '                   |
                               '                   |
                                        +----------v-----------+
                                        |   Service Planning   |
                                        +----------------------+
                                                   |
   +----------------------+    '        +----------v-----------+
   |Service Negotiation   |<---'------->|Service Negotiation   |
   +----------------------+    '        +----------------------+

               Figure 2: Service Advertisement and Discovery

   Local Service Discovery block is responsible for finding remote
   offered services that is an essential input for Service Planning
   block.  This  functional  block  is  responsible  for  choosing  from
   discovered offered services the ones that will be used in order to


Boucadair (Ed.) Standards Track - Expires November 2005        [Page 6]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

   build it own services. Thus, a negotiation process SHOULD start and
   an SLS MAY be agreed between the two parties.

   During service negotiation between two Service Providers, they MAY
   exchange  their  PCE  reachability  information  and  associated
   capabilities. Theses capabilities could include the following:

     o Supported Computation algorithms
     o Types of Constraints (e.g. QoS)
     o Set of attributes for a given constraint (one-way delay, one-way
        delay variationĂ )
     o Support of P2MP path computation techniques,

   As  a  consequence  each  INP  has  a  full  knowledge  of  the  PCE
   capabilities of its adjacent providers.


9.   Why PCE discovery is needed

   Path Computation elements are responsible for finding inter-domain
   paths  satisfying  a  set  of  constraints  (like  QoS  performance
   guarantees) to establish inter-domain constraint-based LSPs. The
   computation of this path is distributed and needs PCEs from different
   domains to communicate. Communication between two PCE entities is
   enabled thanks to inter PCE Communication Protocol (PCP) [INTERAS-
   PCP].

   When receiving a request from the "High-Level" Service Management to
   compute/find a path towards a given tail-end address, the local PCE
   has to determine the next PCE to contact. In the worst case, local
   PCE can contact all its neighboring PCEs that are known to Service
   Management System. Nevertheless, it has no criteria to choose between
   those PCEs the next PCE to be contacted in order to send its path
   computation request. The risk of a request failure is then important.

   In order to help the PCE decision-making process to choose the next
   PCE to be contacted, local PCE need to discover remote PCSvs
   reachable beyond the immediate neighbor PCEs. This information will
   help the next hop PCE decision. PCE need at least access to intra and
   inter-domain Routing Information Bases (RIB) in order to check the
   reachability status of destination prefixes if are propagated thanks
   to routing protocols.


10.    Solution for PCSv discovery

   Within this draft, we assume that during service negotiation phase
   between two peers, they MUST exchange IP addresses of their PCE(s).
   SLS Management Systems of the two peers MUST store this information.



Boucadair (Ed.) Standards Track - Expires November 2005        [Page 7]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

   In order to help the PCE computation process, routing information
   MUST be made available for the PCE. Thus, reachability information
   associated with capabilities (like QoS intra and/or inter-domain
   capabilities) SHOULD be propagated in the routing level. In the case
   of QoS-based service, each potential tail-end address (practically
   all routers interfaces) SHOULD be announced in all offered QoS Class
   plans (i.e. as many as used DSCP values). As a consequence, routing
   tables sizes will drastically increase.

   From this perspective, instead of announcing all potential tail-end
   addresses in BGP, only an identifier needs to be announced. It is
   called  the  Path  Computation  Service  Identifier  (PCSID).  This
   particular BGP announcement is identified by a well-known community
   value (to be defined be IANA) and is represented by a routable IP
   address, which can be different from the real IP address of the PCE.

   As a consequence, this particular route SHOULD NOT be installed in
   the Forwarding Information Base (FIB) since this PCSID is not
   necessarily the IP address of the PCE.

   BGP announcements of PCSID will ease to discover the set of remote
   ASs supporting the inter-AS MPLS-based constrained tunnels service
   together with their associated end-to-end capabilities for reaching
   them. In order to compute a path towards a specific domain supporting
   this inter-AS MPLS-based constrained tunnels service, the local PCE
   chooses a route that serves the PCSID of that domain and extracts
   from the AS_PATH attribute the AS number of the next hop ASBR. Then,
   the local PCE queries its SLS Management system and gets back the
   PCE's IP address of the next neighboring PCE to contact. Finally, the
   local PCE forms and forwards a path computation request to this next
   PCE. The process is iteratively repeated until the request reaches
   the PCE of the target AS identified by its PCSID.

   This solution decreases the number of BGP announcements that are
   reduced to one announcement per AS.


11.    IANA Considerations

   The solution proposed in this draft uses a well-know community
   attribute value that SHOULD be attributed by IANA [RFC2434] in order
   to facilitate recognition of BGP announcements that announce PCSv and
   associated capabilities.


12.    Security Considerations

   This additional draft does not change the underlying security issues
   in the existing BGP-4 protocol specification [RFC2385].



Boucadair (Ed.) Standards Track - Expires November 2005        [Page 8]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

13.    References

   [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
      February 2004

   [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
      Technology", RFC 3668, February 2004

   [CCAMP-FWRK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for
      Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-
      domain-framework-00.txt, August 2004

   [INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing
      inter-AS QoS tunnels", draft-boucadair-pce-interas-01.txt, May
      2005

   [INTERAS-PCP] Boucadair M., Morand P. and al., "Inter-AS PCE
      Communication Protocol", draft-boucadair-pcp-interas-01.txt, May
      2005

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

   [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
      Location Protocol, version 2", RFC 2608, July 1999

   [SLS] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G.,
      Egan R., Griffin D., Georgatsos P., Georgiadis L., Heuven P.V.,
      "Service Level Specification Semantics and parameters", draft-
      tequila-sls-02.txt, Work in progress.

   [RFC1771] Rekhter, Y., Li T., "A Border Gateway Protocol 4 (BGP-4)",
      RFC 1771, March 1995.

   [RFC2434]    Alvestrand, H. and T. Narten, "Guidelines for Writing an
      IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
      1998

   [RFC2385]    Heffernan, A., "Protection of BGP sessions via the TCP
      MD5 Signature Option", RFC 2385, August 1998


14.    Acknowledgments

   Part of this work is funded by the European Commission, within the
   context of the MESCAL (Management of End-to-End Quality of Service
   Across the Internet At Large, http://www.mescal.org) project, which
   is itself part of the IST (Information Society Technologies) research
   program.



Boucadair (Ed.) Standards Track - Expires November 2005        [Page 9]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

   The authors would also like to thank all the partners of the MESCAL
   project for the fruitful discussions.


15.    Author's Addresses

   Mohamed Boucadair
   France Telecom R & D
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4
   France
   Phone: +33 2 31 75 92 31
   Email: mohamed.boucadair@francetelecom.com

   Pierrick Morand
   France Telecom R & D
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4
   France
   Email: pierick.morand@francetelecom.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such  proprietary  rights  by  implementers  or  users  of  this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity


Boucadair (Ed.) Standards Track - Expires November 2005       [Page 10]


Internet Draft      PCE Discovery via Border Gateway            May 2005
                                Protocol

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNETENGINEERING 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.






































Boucadair (Ed.) Standards Track - Expires November 2005       [Page 11]