idnits 2.17.00 (12 Aug 2021) /tmp/idnits15239/draft-boucadair-pce-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 496. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 41 has weird spacing: '...porting inte...' == Line 118 has weird spacing: '...cluding pSLS ...' == Line 123 has weird spacing: '...rmation as i...' == Line 135 has weird spacing: '...element is t...' == Line 152 has weird spacing: '... draft takes...' == (17 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6208 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: draft-ietf-ccamp-inter-domain-framework has been published as RFC 4726 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-inter-domain-framework (ref. 'CCAMP-FWRK') -- Possible downref: Normative reference to a draft: ref. 'INTERAS-PCE' -- Unexpected draft version: The latest known version of draft-boucadair-pcp-interas is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'INTERAS-PCP' == Outdated reference: A later version (-03) exists of draft-tequila-sls-02 -- Possible downref: Normative reference to a draft: ref. 'SLS' ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Boucadair (Ed.) 3 Internet Draft P. Morand (Ed.) 4 France Telecom R&D 5 Document: draft-boucadair-pce-discovery-01.txt May 2005 6 Category: Standards Track 8 Path Computation Service discovery via Border Gateway Protocol 9 < draft-boucadair-pce-discovery-01.txt > 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667 [RFC3667]. By submitting this Internet- 15 Draft, each author represents that any applicable patent or other IPR 16 claims of which he or she is aware have been or will be disclosed, 17 and any of which he or she become aware will be disclosed, in 18 accordance with RFC 3668 [RFC3668]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 2005. 38 Abstract 40 This draft describes a simple mechanism that ease discovery of remote 41 Autonomous Systems (AS) supporting inter-domain MPLS-based 42 constrained tunnels service (this service is also denoted by Path 43 Computation Service (PCSv)) thanks to the use of Path Computation 44 Elements (PCEs). Remote ASs could be managed by a single or distinct 45 Internet Network Providers (INP). 46 Particularly, this draft describes how Border Gateway Protocol (BGP) 47 is used to announce Path Computation Service unique identifiers 48 Protocol 50 across the Internet in order for other PCEs to be able to discover a 51 path towards every AS supporting this Path Computation Service. 53 Table of Contents 55 1. Contributors................................................2 56 2. Changes since last version:.................................2 57 3. Terminology.................................................2 58 4. Introduction................................................3 59 4.1. General.....................................................3 60 4.2. Structure of the draft......................................4 61 5. Conventions used in this document...........................4 62 6. PCE discovery within a single domain........................5 63 7. Overview of the service approach............................5 64 8. Service Advertisement and Discovery.........................6 65 9. Why PCE discovery is needed.................................7 66 10. Solution for PCSv discovery.................................7 67 11. IANA Considerations.........................................8 68 12. Security Considerations.....................................8 69 13. References..................................................9 70 14. Acknowledgments.............................................9 71 15. Author's Addresses.........................................10 73 1. Contributors 75 o Hamid Asgari (Thales Research and Technology) 76 o Panagiotis Georgatsos (Algonet) 77 o David Griffin (University College London) 78 o Micheal Howarth (University of Surrey) 79 o Noel Cantenot (France Telecom) 81 2. Changes since last version: 83 The main changes occurred in this version are: 84 o Rewording of several sections of the draft 86 3. Terminology 88 This memo makes use of the following terms: 90 o Path Computation Element (PCE): an entity that is responsible 91 for computing/finding inter/intra domain paths for establishing 92 LSPs. This entity can simultaneously act as client and a server. 93 Several PCEs could be deployed in a given AS. 95 Protocol 97 o Path Computation Client (PCC): a PCE acting as a client. This 98 entity is responsible for issuing path computation requests that 99 fulfill the Service Management constraints for the establishment 100 of inter/intra domain LSPs. 102 o Path Computation Server (PCS): a PCE acting as a server. This 103 entity is responsible for handling path computation requests in 104 order to satisfy PCC constraints. 106 o High-level service: is the service using a PCE-based system as 107 an underlying infrastructure (an inter-domain QoS VPNs service 108 for instance) 110 o High-level service customer: is a customer that subscribes to a 111 High-level service. 113 o pSLS: A provider SLS is an SLS established between two Internet 114 Network Providers (INP) with the purpose of extending the 115 geographical span of their service offers. 117 o SLS Management: This management entity is responsible for SLS- 118 related activites, including pSLS ordering (i.e establishing 119 contracts between peers) and SLS invocation (i.e committing 120 resources before traffic can be admitted) 122 o q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into 123 account QoS information as input for its route selection 124 process. 126 o Domain: within this draft it denotes an Autonomous system. 128 4. Introduction 130 4.1. General 132 Recently, several proposals describing the use of a Path Computation 133 Element (PCE) as additional element to existent IP network entities 134 have been submitted to the IETF. The main objective of introducing a 135 PCE element is to ease computation of constrained paths in 136 sophisticated schemes like inter-domain (both in intra-provider or 137 inter-provider) and then driving the establishment of inter-domain 138 LSPs. 140 A framework for establishing and controlling Multi-Protocol Label 141 Switching Protocol (MPLS) and Generalized MPLS (GMPLS) Label 142 Switching Paths (LSPs) in multi-domain networks has been defined in 143 [CCAMP-FWRK]. The notion of domain in this framework draft encloses 144 both Interior Gateway Protocol (IGP) areas and Autonomous System (AS) 145 contrary to the current draft that restricts the notion of domain to 146 a single AS. 148 Protocol 150 Another draft that proposes a solution to compute inter-domain 151 constrained paths has been submitted to the IETF [INTERAS-PCE]. This 152 draft takes into account the inter-provider specific service 153 considerations. In addition, the draft [INTERAS-PCP] describes a new 154 protocol allowing communication between two PCEs located in different 155 domains in order to compute inter-domain paths satisfying a set of 156 constraints. 158 All aforementioned drafts require a Path Computation Service (PCSv) 159 discovery function that allows discovery of remote ASs supporting 160 this type of service (the path computation service could be 161 implemented by one or several PCE elements) together with theirs 162 associated capabilities like 163 QoS capabilities, inter-domain bandwidth, reachable IP prefixes, type 164 of links, etc. Discovery of such capabilities could also be passive 165 and be restricted to a simple service advertisement (like web-pages). 166 PCSv locations and associated capabilities discovery depends on 167 providers search. We will refer to this method as passive discovery 168 method. 170 It is evident that passive method allows finding remote PCSv 171 locations and their associated capabilities, but this information is 172 not usable alone within a distributed PCE architecture, when a set of 173 end-to-end constraints must be satisfied. Therefore, computation of 174 end-to-end constraints must be achieved based on advertised 175 individual PCE capabilities. The knowledge of the PCE path is then 176 mandatory in order to deduce the end-to-end capabilities. 178 In this draft, we present a simple method that allows discovery of 179 remote PCSv with their associated capabilities. This method will also 180 help the PCE decision-making process to choose the next PCE to 181 contact in order to optimize paths towards a given destination. 183 4.2. Structure of the draft 185 This draft is structured as follows: 187 o Section 5 gives an overview of the service approach; 188 o Section 6 argues on the need of PCSv discovery functions; 189 o Section 7 presents a solution proposal for PCSv discovery. 191 5. Conventions used in this document 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC-2119 [RFC2119]. 197 Protocol 199 6. PCE discovery within a single domain 201 Within a single domain, discovery of PCSv location and capabilities 202 could be achieved for instance thanks to the activation of the 203 Service Location Protocol (SLP, [RFC2608]). This protocol allows 204 discovery of activated services that uses client/service 205 architecture. SLP defines the same framework for all services. 207 In order to use SLP as a means to discover PCSvs, a PCE Service Type 208 Template SHOULD be defined. 210 7. Overview of the service approach 212 Neighboring domains establish pSLSs (a pSLS is an enhanced SLS 213 agreement between two providers. SLS template is defined in [SLS]) 214 between them in order to have appropriate rights to request 215 establishment of LSPs. An inter-domain routing protocol runs between 216 the domains (for instance Border Gateway Protocol (BGP, [RFC1771])). 217 The LSP creation request is propagated downstream to appropriate 218 PCEs. The requests include the AS's ASBR and the tail-end address of 219 the LSP. This procedure is repeated until the request reaches the 220 destination PCE. 222 +--------High Level Service Agreement--------+ 223 | | 224 v v 225 <----AS1-----> <----AS2-----> <----AS3-----> 226 ' ' ' ' ' ' 227 ' '<-pSLS->' '<- pSLS->' ' 228 ' ' ' ' ' ' 229 +------------+ +------------+ +------------+ 230 | PCE | | PCE | | PCE | 231 | | | | | | 232 | +------+ | | +------+ | | +------+ | 233 | | PCC | | | | PCC | | | | PCC | | 234 | | |<-|--\ | | |<-|--\ | | | | 235 | +--/\--+ | | | +--/\--+ | | | +--/\--+ | 236 | || | |PCP | || | |PCP | || | 237 | || | | | || | | | || | 238 | +--\/--+ | | | +--\/--+ | | | +--\/--+ | 239 | | PCS | | \-----|->| PCS | | \------|->| PCS | | 240 | | | | | | | | | | | | 241 | +------+ | | +------+ | | +------+ | 242 +------------+ +------------+ +------------+ 244 Figure 1: Service Overview 246 After authenticating the identity of LSP originating PCE, the 247 destination PCE send a reply message back to the downstream domain's 248 Protocol 250 PCE accepting the request and include the LSP loose path 251 (destination, ASBR) addresses in the message. The next downstream 252 domain's PCE does the same and adds its own relevant ASBR addresses 253 to the loose path. The originating PCE inserts its intra-domain path 254 and then initializes an RSVP reservation request for LSP 255 establishment using the returned loose path. 257 At the service/application level (in order to differentiate this 258 service from extending scope of IP connectivity service, we will 259 denote it as high level service), when originating AS wants to 260 establish an LSP to a destination in a remote ASs, there MUST be an 261 agreement between the two ASs. 263 8. Service Advertisement and Discovery 265 Within this draft, we make a difference between the Service 266 Advertisement and Discovery (SAD) and PCSv discovery function. SAD is 267 a function that is achieved before establishing a service agreement 268 between two peers. The SAD operation consists mainly at 269 advertising/learning from/to the rest of the Internet the 270 capabilities supported by a given AS in term of offered services 271 (like Inter-domain LSP establishment service). PCSv advertisement is 272 conditioned by the existence of a pSLS between two peers. 274 AS1 ' AS2 275 ' 276 +----------------------+ ' 277 |Service Advertisement |<---'-------------------\ 278 +----------------------+ ' | 279 ' | 280 +----------v-----------+ 281 | Service Discovery | 282 +----------------------+ 283 ' | 284 ' | 285 +----------v-----------+ 286 | Service Planning | 287 +----------------------+ 288 | 289 +----------------------+ ' +----------v-----------+ 290 |Service Negotiation |<---'------->|Service Negotiation | 291 +----------------------+ ' +----------------------+ 293 Figure 2: Service Advertisement and Discovery 295 Local Service Discovery block is responsible for finding remote 296 offered services that is an essential input for Service Planning 297 block. This functional block is responsible for choosing from 298 discovered offered services the ones that will be used in order to 299 Protocol 301 build it own services. Thus, a negotiation process SHOULD start and 302 an SLS MAY be agreed between the two parties. 304 During service negotiation between two Service Providers, they MAY 305 exchange their PCE reachability information and associated 306 capabilities. Theses capabilities could include the following: 308 o Supported Computation algorithms 309 o Types of Constraints (e.g. QoS) 310 o Set of attributes for a given constraint (one-way delay, one-way 311 delay variationà) 312 o Support of P2MP path computation techniques, 314 As a consequence each INP has a full knowledge of the PCE 315 capabilities of its adjacent providers. 317 9. Why PCE discovery is needed 319 Path Computation elements are responsible for finding inter-domain 320 paths satisfying a set of constraints (like QoS performance 321 guarantees) to establish inter-domain constraint-based LSPs. The 322 computation of this path is distributed and needs PCEs from different 323 domains to communicate. Communication between two PCE entities is 324 enabled thanks to inter PCE Communication Protocol (PCP) [INTERAS- 325 PCP]. 327 When receiving a request from the "High-Level" Service Management to 328 compute/find a path towards a given tail-end address, the local PCE 329 has to determine the next PCE to contact. In the worst case, local 330 PCE can contact all its neighboring PCEs that are known to Service 331 Management System. Nevertheless, it has no criteria to choose between 332 those PCEs the next PCE to be contacted in order to send its path 333 computation request. The risk of a request failure is then important. 335 In order to help the PCE decision-making process to choose the next 336 PCE to be contacted, local PCE need to discover remote PCSvs 337 reachable beyond the immediate neighbor PCEs. This information will 338 help the next hop PCE decision. PCE need at least access to intra and 339 inter-domain Routing Information Bases (RIB) in order to check the 340 reachability status of destination prefixes if are propagated thanks 341 to routing protocols. 343 10. Solution for PCSv discovery 345 Within this draft, we assume that during service negotiation phase 346 between two peers, they MUST exchange IP addresses of their PCE(s). 347 SLS Management Systems of the two peers MUST store this information. 349 Protocol 351 In order to help the PCE computation process, routing information 352 MUST be made available for the PCE. Thus, reachability information 353 associated with capabilities (like QoS intra and/or inter-domain 354 capabilities) SHOULD be propagated in the routing level. In the case 355 of QoS-based service, each potential tail-end address (practically 356 all routers interfaces) SHOULD be announced in all offered QoS Class 357 plans (i.e. as many as used DSCP values). As a consequence, routing 358 tables sizes will drastically increase. 360 From this perspective, instead of announcing all potential tail-end 361 addresses in BGP, only an identifier needs to be announced. It is 362 called the Path Computation Service Identifier (PCSID). This 363 particular BGP announcement is identified by a well-known community 364 value (to be defined be IANA) and is represented by a routable IP 365 address, which can be different from the real IP address of the PCE. 367 As a consequence, this particular route SHOULD NOT be installed in 368 the Forwarding Information Base (FIB) since this PCSID is not 369 necessarily the IP address of the PCE. 371 BGP announcements of PCSID will ease to discover the set of remote 372 ASs supporting the inter-AS MPLS-based constrained tunnels service 373 together with their associated end-to-end capabilities for reaching 374 them. In order to compute a path towards a specific domain supporting 375 this inter-AS MPLS-based constrained tunnels service, the local PCE 376 chooses a route that serves the PCSID of that domain and extracts 377 from the AS_PATH attribute the AS number of the next hop ASBR. Then, 378 the local PCE queries its SLS Management system and gets back the 379 PCE's IP address of the next neighboring PCE to contact. Finally, the 380 local PCE forms and forwards a path computation request to this next 381 PCE. The process is iteratively repeated until the request reaches 382 the PCE of the target AS identified by its PCSID. 384 This solution decreases the number of BGP announcements that are 385 reduced to one announcement per AS. 387 11. IANA Considerations 389 The solution proposed in this draft uses a well-know community 390 attribute value that SHOULD be attributed by IANA [RFC2434] in order 391 to facilitate recognition of BGP announcements that announce PCSv and 392 associated capabilities. 394 12. Security Considerations 396 This additional draft does not change the underlying security issues 397 in the existing BGP-4 protocol specification [RFC2385]. 399 Protocol 401 13. References 403 [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, 404 February 2004 406 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 407 Technology", RFC 3668, February 2004 409 [CCAMP-FWRK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for 410 Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- 411 domain-framework-00.txt, August 2004 413 [INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing 414 inter-AS QoS tunnels", draft-boucadair-pce-interas-01.txt, May 415 2005 417 [INTERAS-PCP] Boucadair M., Morand P. and al., "Inter-AS PCE 418 Communication Protocol", draft-boucadair-pcp-interas-01.txt, May 419 2005 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997 424 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 425 Location Protocol, version 2", RFC 2608, July 1999 427 [SLS] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., 428 Egan R., Griffin D., Georgatsos P., Georgiadis L., Heuven P.V., 429 "Service Level Specification Semantics and parameters", draft- 430 tequila-sls-02.txt, Work in progress. 432 [RFC1771] Rekhter, Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", 433 RFC 1771, March 1995. 435 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 436 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 437 1998 439 [RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP 440 MD5 Signature Option", RFC 2385, August 1998 442 14. Acknowledgments 444 Part of this work is funded by the European Commission, within the 445 context of the MESCAL (Management of End-to-End Quality of Service 446 Across the Internet At Large, http://www.mescal.org) project, which 447 is itself part of the IST (Information Society Technologies) research 448 program. 450 Protocol 452 The authors would also like to thank all the partners of the MESCAL 453 project for the fruitful discussions. 455 15. Author's Addresses 457 Mohamed Boucadair 458 France Telecom R & D 459 42, rue des Coutures 460 BP 6243 461 14066 Caen Cedex 4 462 France 463 Phone: +33 2 31 75 92 31 464 Email: mohamed.boucadair@francetelecom.com 466 Pierrick Morand 467 France Telecom R & D 468 42, rue des Coutures 469 BP 6243 470 14066 Caen Cedex 4 471 France 472 Email: pierick.morand@francetelecom.com 474 Intellectual Property Statement 476 The IETF takes no position regarding the validity or scope of any 477 Intellectual Property Rights or other rights that might be claimed to 478 pertain to the implementation or use of the technology described in 479 this document or the extent to which any license under such rights 480 might or might not be available; nor does it represent that it has 481 made any independent effort to identify any such rights. Information 482 on the procedures with respect to rights in RFC documents can be 483 found in BCP 78 and BCP 79. 485 Copies of IPR disclosures made to the IETF Secretariat and any 486 assurances of licenses to be made available, or the result of an 487 attempt made to obtain a general license or permission for the use of 488 such proprietary rights by implementers or users of this 489 specification can be obtained from the IETF on-line IPR repository at 490 http://www.ietf.org/ipr. 492 The IETF invites any interested party to bring to its attention any 493 copyrights, patents or patent applications, or other proprietary 494 rights that may cover technology that may be required to implement 495 this standard. Please address the information to the IETF at 496 ietf-ipr@ietf.org. 498 Disclaimer of Validity 499 Protocol 501 This document and the information contained herein are provided on an 502 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 503 REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 504 INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 505 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 506 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 507 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 509 Copyright Statement 511 Copyright (C) The Internet Society (2005). This document is subject 512 to the rights, licenses and restrictions contained in BCP 78, and 513 except as set forth therein, the authors retain all their rights.