idnits 2.17.1 draft-salsano-bgrpp-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 14) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 80 looks like a reference -- Missing reference section? '2' on line 335 looks like a reference -- Missing reference section? '3' on line 98 looks like a reference -- Missing reference section? '4' on line 114 looks like a reference -- Missing reference section? '5' on line 121 looks like a reference -- Missing reference section? 'PH' on line 573 looks like a reference -- Missing reference section? 'IN' on line 789 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Stefano Salsano (ed.), CoRiTeL 2 Vincenzo Genova, CoRiTeL 3 Fabio Ricciato, CoRiTeL 4 May, 2002 Martin Winter, Siemens AG 5 Expiration: November, 2002 Bert F. Koch, Siemens AG 6 Lila Dimopoulou, NTUA 7 Eugenia Nikolouzou, NTUA 8 Petros D. Sampatakos, NTUA 9 Iakovos S. Venieris, NTUA 10 Gerald Eichler, T-Systems Nova GmbH 12 Inter-domain QoS Signaling: the BGRP Plus Architecture 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 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 Distribution of this memo is unlimited. 38 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 DiffServ architecture provides a set of "user plane" tools for IP QoS. 44 Deployment of DiffServ is starting with static, single-domain solutions. 45 Dynamic QoS and multi-domain QoS are still open issues, as witnessed by 46 the activity of the IETF NSIS WG, related to the "signaling plane". 47 In order to realize true end-to-end QoS services in the Internet, 48 spanning multiple administrative domains, efficient and scalable 49 signaling and resource control mechanisms are needed. 51 This document describes a scalable inter-domain resource control 52 architecture for DiffServ networks. The architecture is called BGRP 53 Plus, as it extends the previously proposed BGRP framework. 55 S. Salsano (ed.) Expires November 2002 1 56 Table of Contents 58 1. Introduction.................................................4 59 2. Requirements for inter-domain resource reservation...........5 60 3. Reference Network............................................6 61 4. Scalability of inter-domain resource reservation.............7 62 5. Quiet grafting...............................................8 63 6. Inter-domain QoS and Globally Well Known Services............10 64 7. BGRPP messages...............................................10 65 8. BGRPP procedures.............................................11 66 9. BGRP+ and BGRP...............................................13 67 10. Acknowledgements............................................14 68 11. Author Information..........................................14 69 12. References..................................................15 70 13. APPENDIX A: PSEUDO CODE for Message Processing..............15 72 S. Salsano (ed.) Expires November 2002 2 73 1. Introduction 75 The DiffServ architecture specifies a set of "user plane" mechanisms, 76 which can be used to provide QoS in IP networks. Intentionally, the IETF 77 DiffServ WG has not covered any "signaling plane" aspect. QoS signaling 78 capabilities are indeed needed to extend the provisioning of QoS in IP 79 networks from a static model towards a dynamic one. The IETF WG NSIS 80 (Next Steps In Signaling) [1] has been specifically chartered to address 81 the signaling aspects of QoS in IP networks. The NSIS WG is currently 82 defining the requirements for the QoS signaling mechanisms, and is 83 considering a set of reference scenarios. One of these scenarios is the 84 QoS reservation/ negotiation over administrative boundaries or "inter- 85 domain" QoS. 86 A fundamental issue in the definition of an inter-domain QoS model is 87 the scalability, because the ambitious goal is to support QoS services 88 on the scale of the global Internet. 90 This draft proposes an architecture that originates from the BGRP 91 protocol framework proposed in [2], providing "sink tree" based 92 aggregation for resource reservations over a network of DiffServ 93 domains. The aggregated reservations are negotiated between so-called 94 BGRP agents, which are deployed at each BGP-capable border router of 95 each DiffServ domain. In this way, each domain can perform some kind of 96 admission control, taking into account the available resources within 97 that domain. By aggregating the reservations according to the sink trees 98 created by the BGP routing protocol [3], the number of reservations and 99 thus the amount of state information stored in the network can be 100 reduced. 102 However, aggregation of reservations is just the first step towards 103 scalability. To limit the signaling load and the processing power 104 required in the BGRP agents, it is also necessary to reduce the number 105 of signaling messages. We propose mechanisms for the early response to 106 reservation messages, in [2] called "quiet grafting", so that not each 107 message has to travel edge-to-edge through the DiffServ network region. 108 The architecture proposed in this draft is called BGRP Plus (BGRPP or 109 BGRP+). 111 As regards the applicability of this proposal: 112 1) The BGRPP architecture has been implemented in the context of the 113 AQUILA IST project, where a specific access QoS signaling mechanism 114 has been defined [4]. 115 2) The BGRPP architecture is largely compliant to the requirements for 116 the QoS signaling under definition by NSIS WG. 117 3) Considering the IntServ over DiffServ architecture as described in 118 [5], then an efficient and scalable resource control is also 119 essential within the DiffServ region. BGRPP may be a more scalable 120 answer to this need, with respect to the "RSVP-aware DiffServ 121 region", which is proposed in [5]. 123 S. Salsano (ed.) Expires November 2002 3 124 Our discussion is focused on technical aspects and even if we mention 125 the Service Level Agreements (SLAs) the discussion of financial and 126 legal aspects of the inter-domain services is intentionally omitted. 128 2. Requirements for inter-domain resource reservation 130 An architecture and related protocol for inter-domain resource 131 reservation should meet the requirements listed in the following 132 paragraphs. BGRP is a good candidate to meet them. 134 2.1 Scalability 136 The architecture has to scale well with the Internet size and growth. 138 2.2 Autonomous operation 140 Admission control should be made autonomously in each domain. Each 141 domain's network operator can independently administer his network and 142 configure the behavior of inter-domain resource reservation elements 143 independently each other. 145 2.3 Follow established routes 147 Inter-domain resource reservation shall rely on inter-domain routing 148 (e.g. BGP) for routing decisions. An interface has to be defined between 149 inter-domain routing and inter-domain resource reservation to allow the 150 latter to retrieve routing information (e.g. the NEXT_HOP). We assume 151 that BGP remains unaffected by the inter-domain resource reservation 152 architecture. 154 2.4 Independence of each domain 156 The inter-domain protocol should be independent of the intra-domain 157 resource control architecture. A domain may use static provisioning as 158 well as dynamic resource allocation. However, a common interface between 159 intra-domain and inter-domain resource control has to be defined. 161 2.5 Influence of SLA and SLS 163 In the inter-domain scope, the most important constraint is not an 164 optimization of network resources but the conformity to the SLA with the 165 neighbor. Each domain has many neighbors, from just a few up to 166 hundreds, and the administrator signs a contract with each of them. When 167 a request for a reservation to another AS reaches a BR, it has to choose 168 a "next hop" to forward the request: if the next hop belongs to another 169 AS, the BR should make sure that the request is in compliance with the 170 SLA. 172 S. Salsano (ed.) Expires November 2002 4 173 3. Reference Network 175 The architecture described in this document assumes a DiffServ region 176 consisting of several connected, but administratively separated domains. 177 The traffic can enter and leave the domains at two different types of 178 routers: 180 - An edge router (ER) connects a domain to a network, which is not 181 taking part in the BGRPP resource allocation mechanism, e.g. an 182 access network. 184 - A border router (BR) connects a domain to another domain, which 185 also takes part in the BGRPP resource allocation mechanism. 187 ___ ________ ________ ________ ___ 188 \ / \ / \ / \ / 189 \ / \ / \ / \ / 190 |---| |---| |---| |---| |---| |---| |---| |---| 191 | R1|-|ER1| |BR1|---|BR2| |BR3|---|BR4| |ER2|-|R2 | 192 |---| |---| |-- | |---| |---| |---| |---| |---| 193 / \ / \ / \ / \ 194 ___/ \________/ \________/ \________/ \___ 196 Access Source Transit Destination Access 197 network domain domain domain network 199 Figure 1: Reference network configuration 201 A source or destination domain is a domain with at least one edge 202 router. A transit domain is a domain with at least two border routers, 203 which forwards traffic received at one border router to another border 204 router. All edge routers and border routers are required to run BGP. 206 Corresponding to each border router, a BGRP agent is instantiated as 207 shown in the following figure: 209 |-----| |-----| |-----| |-----| 210 |BGRPP|-|BGRPP|--|BGRPP|-|BGRPP| 211 |-----| |-----| |-----| |-----| 212 : : : : 213 ___ ________: :________: :________ ___ 214 \ / \ / \ / \ / 215 \ / :\ /: :\ /: \ / 216 |---| |---| |---| |---| |---| |---| |---| |---| 217 | R1|-|ER1| |BR1|---|BR2| |BR3|---|BR4| |ER2|-|R2 | 218 |---| |---| |-- | |---| |---| |---| |---| |---| 219 / \ / \ / \ / \ 220 ___/ \________/ \________/ \________/ \___ 222 Access Source Transit Destination Access 223 network domain domain domain network 225 Figure 2: BGRPP agents 227 S. Salsano (ed.) Expires November 2002 5 228 We assume that the source domain is capable of performing some kind of 229 per flow admission control, taking into account the available resources 230 up to BR1. The source domain has however no information about the 231 availability of resources along the further path of the reservation 232 through other domains. 234 To perform inter-domain admission control, the source domain determines 235 the egress border router and contacts the corresponding BGRPP agent. 236 Through the BGRPP protocol this agent is able to determine, whether 237 resources are available in each domain along the path and on the links 238 connecting the domains. Each BGRPP agent cares for the resources on the 239 next path segment from its associated border router towards the 240 destination. 242 Resource reservation in the source and destination domain is not the 243 task of the BGRPP protocol. However, as we describe later, BGRPP has to 244 provide mechanisms to enable resource reservation in the destination 245 domain. 247 There are mainly two types of messages involved in the reservation set- 248 up: 250 - PROBE messages are initiated at the source domain and are 251 forwarded between BGRPP agents along the BGP path. They check the 252 conformance of the request with the SLAs between neighbored 253 domains. The path is recorded in the message, to enable the 254 response to take the same way in the backward direction. 255 - GRAFT messages indicate the availability of resources towards the 256 destination domain. During message processing, the resource 257 availability is checked and the resources are actually reserved in 258 each path segment. 260 4. Scalability of inter-domain resource reservation 262 BGRPP is an inter-domain protocol to allow resource reservation. The 263 main issue that BGRPP should tackle is the scalability problem. 264 This problem is related to two aspects: 266 - the handling of state information for each reserved flow and 267 - the processing of reservation messages. 269 In particular, the scalability problem is related to: 271 - memory needs for each router that runs reservation protocol; 272 - CPU usage for message processing; 273 - bandwidth utilization for messages. 275 A scalable solution will minimize these three elements. 277 BGRP as described in [2] mainly addresses the scalability in terms of 278 the amount of state information kept in each BGRP agent. It aggregates 280 S. Salsano (ed.) Expires November 2002 6 281 reservations along the BGP sink trees and thus achieves a scalability 282 behavior, where the memory requirements are proportional to the number 283 of sink trees with simultaneous active reservations. 285 However, in order to check the resource availability, BGRP messages have 286 still to travel along the full path to the destination domain, asking 287 each BGRP agent to check the resource availability for that part of the 288 network it is responsible for. So the message processing overhead may be 289 rather large, especially in big backbone networks. 291 In order to solve this problem, an hint is given in [2]: resources may 292 be kept in advance at a BGRP agent, so that further requests may be 293 already terminated at an earlier stage. In this document we provide the 294 complete functional specification of this mechanism, called "quiet 295 grafting". Together with the sink-tree-based aggregations, this 296 mechanism provides a scalable solution for inter-domain resource 297 reservations. 299 5. Quiet grafting 301 5.1 Requirements 303 When an inter-domain reservation is initiated at a source domain, the 304 first BGRPP agent constructs a PROBE message indicating the amount of 305 bandwidth required and the destination address. It is not evident, to 306 which sink tree this reservation will belong. So the PROBE message is 307 forwarded hop-by-hop between BGRPP agents along the BGP route to the 308 destination. Obviously, the last BGRPP agent, which corresponds to the 309 root of the sink tree, can assign a sink tree id to the reservation. The 310 GRAFT message sent back will contain this sink tree id. As this message 311 travels back to the source domain, it installs the necessary sink tree 312 reservations in the path segments. 314 To enable an intermediate BGRPP agent to answer a PROBE message 315 successfully with a positive response, the following conditions have to 316 be met: 318 - The BGRPP agent must be able to determine the sink tree, to which 319 the reservation belongs. 320 - The BGRPP agent must have pre-reserved resources for this sink 321 tree, so that he can guarantee, that the resources are available 322 on the path segment from the current point to the destination 323 domain. 324 - As the last BGRPP agent may no longer be informed about a new 325 reservation, the BGRPP agent must provide means to contact the 326 destination domain, so that resources can also be reserved on the 327 not-BGRPP-controlled path segment from BR4 to ED2 (see figure 2). 329 The following paragraphs describe the solutions we propose to solve 330 these requirements. 332 S. Salsano (ed.) Expires November 2002 7 333 5.2 NLRI Labeling for Sink Tree Identification 335 According to [2], a sink tree is identified by the destination AS number 336 and a border router id. The network layer reachability information 337 (NLRI) associated with the root of the tree can be used to identify the 338 tree at a distant point in the network. As BGP may aggregate this 339 information into aggregated routes, it is not directly derivable from 340 BGP routing information. Instead, we propose to propagate the NLRI back 341 from the root of the sink tree in GRAFT messages and to store this 342 information in each BGRPP agent, which processes the message. 344 When a new PROBE message arrives, the BGRPP agent will compare the 345 destination address with the already stored NLRI thus trying to identify 346 the sink tree. Successful sink tree identification is a prerequisite to 347 the following steps, to perform successful quiet grafting. 349 To reduce memory requirements, BGRPP agents will only store NLRI 350 information for those sink trees, where actual reservations exist. 352 5.3 Pre-reservation 354 When a BGRPP agent processing a PROBE message was able to determine the 355 sink tree, he will now check, whether he has pre-reserved resources on 356 this sink tree. If this is the case, he can generate a GRAFT message and 357 terminate the PROBE at this stage. If there are not sufficient resources 358 available, the BGRPP agent will further forward the GRAFT message to the 359 next BGRPP agent, as determined by the NEXT_HOP attribute of the BGP 360 path to the destination. 362 The amount of pre-reserved resources that is available at a given time 363 for a sink tree is called resource cushion. A possible solution to build 364 this resource cushion at each BGRPP agent is the "delayed resource 365 release" mechanism. This means, that a BGRPP agent will not immediately 366 release unused resources, but instead keep them in an attempt to satisfy 367 further requests. Resources are however released, when they are unused 368 for some time. 370 We will describe the proposed algorithm in a separate document and 371 provide information about its performance in various scenarios. 373 5.4 Signaling in the last domain 375 When a PROBE message is answered "in advance", the last domain may not 376 be informed about the new request and cannot reserve resources within 377 that domain. To include the resource availability in the last domain in 378 the overall admission control, we propose to back-propagate a reference 379 to the interface to intra-domain resource control at the root of the 380 sink tree within the GRAFT message. This information is also stored 381 within each BGRPP agent that handles this message. 383 The originating BGRPP agent can then use this reference to directly 384 request the required resources in the destination domain. 386 S. Salsano (ed.) Expires November 2002 8 387 This reference is also necessary for the release of a reservation: since 388 resources are not immediately released, when the original end-user 389 request is removed, possibly the destination domain will not be informed 390 at all about this event. For this purpose it is necessary that the 391 originator of the request can directly inform the destination domain. 393 6. Inter-domain QoS and Globally Well Known Services 395 In the previous sections we have mentioned "reservations" which are 396 originated by a source domain (and propagated up to the destination 397 domain) and are characterized by a bandwidth parameter. Actually, a 398 reservation should be also be characterized by the required service and 399 other parameters besides the bandwidth could be needed. We assume that a 400 set of "Globally Well Known Services" is defined to characterize the 401 required service. For the sake of simplicity, in the following 402 description of messages and procedures, we also assume that the 403 bandwidth is the only needed parameter. 405 7. BGRPP messages 407 7.1 PROBE message 408 It consists of a reservation request and destination network 409 information. It travels from origin AS towards destination AS and 410 collects routing information. It contains the information of the 411 requested amount of resources. 413 The fields of PROBE message are: 415 Sender: It is a BGRPP agent identifier, it is composed of AS id 416 and the IP address of BR that has sent the PROBE. 417 ProbeId: The origin AS chooses the ProbeId. The ProbeID scope is 418 local to the originating BGRPP agent and only used there 419 to match the GRAFT (or ERROR) message. In other words, 420 only the originating AS stores a "PROBE state" while 421 Intermediate ASs nodes does not need correlate PROBE and 422 GRAFT. 423 GwksId: GWKS id 424 Destination: IP address prefix of the host or network that is 425 destination of request 426 RequiredBW: Requested bw [bit/s] 427 TreeId: Id of sink tree, it is NULL if the sink tree is unknown. 428 This information is actually redundant, as each node could 429 check weather the Destination matches an existing sink 430 tree. By avoiding this check, it enhances the 431 performances. 432 Path: Record of the route in terms of BGRPP agents from origin 433 AS 435 7.2 GRAFT message 436 When the destination AS (or a transit AS if it can do quiet grafting) 437 receives a PROBE and it can accept the request, it returns a GRAFT 439 S. Salsano (ed.) Expires November 2002 9 440 towards the origin AS, using the Path information collected by PROBE 441 message. This message carries sink tree information. It also carries the 442 amount of resources that are reserved by the node sending the GRAFT. 444 The fields of GRAFT message are: 445 Sender: It is a BGRPP agent identifier, it is composed of AS id 446 and the IP address of BR that has sent the GRAFT. 447 Id: Msg id to match GRAFT with PROBE, echoed from PROBE 448 GwksId: GWKS id 449 Destination: Ip address prefix of the host or network that is 450 destination of request, echoed from PROBE 451 ReservedBW: Reserved bw [bit/s] 452 TreeId: Id of sink tree 453 DestResMgr: Reference to destination domain reservation manager for 454 reservation in the last domain 455 AddressPrefixList: NLRI 456 Path: Record of the route in terms of BGRPP agents to be 457 followed back 459 7.3 REFRESH message 460 It contains the indication of the current amount of needed BW. 461 It is sent by a previous (upstream) node to reduce the amount of 462 requested resource. A REFRESH with zero bandwidth is used to tear down a 463 reservation. 464 REFRESH messages must never be used by a previous (upstream) node to 465 increase the amount of requested resources. 467 Sender: It is a BGRPP agent identifier, it is composed of AS id 468 and the IP address of BR that has sent the REFRESH. 469 GwksId: GWKS id 470 ActualBw: actual reserved bandwidth 471 TreeId: id of sink tree 473 7.4 ERROR message 474 It indicates that some error has occurred. It contains a description of 475 the specific error case. For example if the resources are not available, 476 an ERROR message is sent and propagated backwards up to the originator 477 of the request. 479 7.5 TEAR message 480 It was defined in the BGRP architecture. Currently, it has no use in the 481 BGRPP architecture, because it is replaced by the use of refresh 482 messages. 484 8. BGRPP procedures 486 8.1 State information in BGRPP agents 488 In order to process the BGRPP protocol messages, the BGRPP agent stores 489 the following sink tree status information: 491 S. Salsano (ed.) Expires November 2002 10 492 For each sink tree (with at least one reservation) and for each service, 493 the next ("outgoing") hop and a list of previous ("incoming") hops is 494 stored. The value of reserved resources for the outgoing hop and for 495 each incoming hop is stored (this information is replicated per each 496 GWKS). 498 For each sink tree, the NLRI is stored, to enable sink tree 499 identification for quiet grafting (see 5.2). Additionally, a reference 500 to the intra-domain resource control of the destination domain is 501 stored, to enable signaling to the last domain (see 5.4). 503 TABLE 1 - Sink tree x state information 504 ----------------------------------------------------------------------- 505 Next hop IP address of next hop BGRPP agent 506 Outgoing.res[g]Reserved BW for the sink tree x towards the Next hop 507 for the GWKS g 508 Previous hop[i]IP addresses of previous hop BGRPP agents 509 Incoming[i].res[g] Reserved BW for the sing tree assigned to each 510 Previous hop for the GWKS g 511 NLRI NLRI for the sink tree 512 Intra-dom. RC Ref. Reference to the intra-domain resource control of 513 the destination domain 514 ----------------------------------------------------------------------- 516 The resource cushion is the difference between the Outgoing.res and the 517 sum of the Incoming[i].res. 519 8.2 Message handling 521 (In the following the dependence from the GWKS g will always be 522 omitted). 523 The message handling for a transit AS is described, the procedures for 524 Originating AS and Terminating AS can be derived. In APPENDIX A a more 525 complete pseudo-code description of the message handling is provided. 527 - PROBE messages 529 The PROBE messages can be: 530 - rejected because SLA/SLS does not match or there are no resources 531 on outgoing link or on intra-domain links 532 - accepted with Quiet Grafting 533 - forwarded to downstream node with no change in RequiredBW 535 When a PROBE is received a preliminary admission control is performed. 536 If the BGRPP agent is at an ingress Border Router, it checks for SLA 537 between the requester AS and its own AS and decides if the request can 538 be accepted. The BGRPP agent could also check if intra-domain resource 539 manager could accept the new request. If the BGRPP agent is associated 540 to an egress BR it has to check the SLA with the AS of next hop BR. It 541 can also check for the resources on the outgoing link towards the next 542 hop BR. 544 S. Salsano (ed.) Expires November 2002 11 545 If any of these checks fail, the request cannot be accepted and an ERROR 546 message is sent to previous hop. 547 If the checks are OK, the node (both the ingress and the egress BR) 548 first verifies if the Destination of the PROBE matches an existing sink 549 tree. In this case it is first checked if the resource cushion can fit 550 the RequiredBW. In case of positive answer, Quiet Grafting is performed: 551 the Incoming[PH].res related to the previous hop is increased by the 552 RequiredBW value and a GRAFT message is sent to the Previous hop. If the 553 Destination of the PROBE does not match an existing sink tree, or the 554 resource cushion is not enough, the PROBE is forwarded and the state 555 information of the node is not touched in any way. 557 - GRAFT messages 559 The resource reservation is performed when a GRAFT arrives. A GRAFT 560 tells the receiving node the downstream node can accept a given amount 561 of BW for a given sink tree. Now the receiving node should decide if it 562 has the resources to send this amount of BW towards the next hop BR and 563 if the SLA matches. In particular, an Ingress BR should check the 564 Incoming SLS with upstream AS and should consider the availability of 565 intra-domain resources towards egress BR. An Egress BR should check the 566 Outgoing SLS towards the downstream AS and should consider the resources 567 on the outgoing link towards the Ingress BR of the downstream AS. (The 568 nodes could have already performed these checks during PROBE phase, but 569 the situation could have changed). 570 If the resources are available and SLA/SLS matches, the graft is 571 accepted and the node: 572 1) Increases the Outgoing.res by the ReservedBW value. 573 2) Increases the Incoming[PH].res of the Previous hop PH by the 574 ReservedBW value. 575 3) Propagates the GRAFT to the Previous hop. 576 If the resources are not available or (incoming/outgoing) SLA/SLS not 577 matching, the GRAFT cannot be accepted. The node will immediately send 578 an ERROR towards the first originator of the PROBE. If the reason of 579 refusal is outgoing SLA not matching or unavailability of resources, the 580 node has also to release reserved BW to next hop because it can not 581 utilize it. To this purpose the node sends a REFRESH message to its next 582 hop. If the reason of refusal is incoming SLA not matching the node can 583 maintain the additional reserved BW towards its next hop to enlarge 584 resource cushion. 586 9. BGRP+ and BGRP 588 It is worth to recall the extensions of this draft with respect to the 589 original BGRP proposal: 590 - The architecture includes the aspects related to the interactions 591 with intra-domain resource reservation mechanisms 592 - The quiet grafting mechanisms simply mentioned in the BGRP 593 proposal has been fully specified 594 - The mechanisms to match a flow into the sink-tree by means of the 595 NLRI information and to distribute this NLRI information where 596 needed have been specified 598 S. Salsano (ed.) Expires November 2002 12 599 - The issue of the missing signaling in the last domain due to quiet 600 grafting has been addressed and resolved 601 - The semantic content of the messages has been described 602 - The procedures for message handling have been given (both in text 603 and using a pseudo-code) 605 10. Acknowledgements 607 Part of this work has been funded under the European Commission 5th 608 framework IST program. 610 The authors would like to acknowledge all their colleagues in the AQUILA 611 project for their important contribution to this work. 613 11. Author Information 615 Stefano Salsano 616 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 617 Via Anagnina, 203 618 00040 Morena Roma - ITALY 619 e-mail: salsano@coritel.it 621 Vincenzo Genova, CoRiTeL 622 e-mail: genova@coritel.it 624 Fabio Ricciato, CoRiTeL 625 e-mail: ricciato@coritel.it 627 Martin Winter, 628 Siemens AG, ICN WN CC EK A19 629 81359 Munich - Germany 630 e-mail: martin.winter@icn.siemens.de 632 Bert F. Koch, Siemens AG 633 e-mail: bert.koch@icn.siemens.de 635 Lila Dimopoulou 636 NTUA - National Technical University of Athens 637 Heroon Polytechniou 9, 157 73, Athens GREECE 638 e-mail: lila@telecom.ntua.gr 640 Eugenia Nikolouzou, NTUA 641 e-mail: enik@telecom.ntua.gr 643 Petros D. Sampatakos, NTUA 644 e-mail: psampa@telecom.ntua.gr 646 Iakovos S. Venieris, NTUA 647 e-mail: ivenieri@cc.ece.ntua.gr 649 Gerald Eichler, T-Systems Nova GmbH 651 S. Salsano (ed.) Expires November 2002 13 652 e-mail: Gerald.Eichler@t-systems.com 654 12. References 656 [1]M. Brunner (Editor), "Requirements for QoS Signaling Protocols", 657 draft-ietf-nsis-req-01.txt, April 2002, Work in Progress 658 [2]P. Pan, E. Hahne, H. Schulzrinne: "BGRP: Sink-Tree-Based 659 Aggregation for Inter-Domain Reservations", Journal of 660 Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167, 662 http://www.cs.columbia.edu/~pingpan/papers/bgrp.pdf 663 [3]Y. Rekhter, T.J. Watson, T. Li: "A Border Gateway Protocol 4 (BGP- 664 4)", RFC 1771, March 1995 665 [4]AQUILA IST Project http://www.ist-aquila.org/ 666 [5]Y. Bernet et al., "Integrated Services Over Diffserv Networks", RFC 667 2998, November 2000 669 13. APPENDIX A: PSEUDO CODE for Message Processing 671 13.1 PROBE processing 672 // State variables for PROBE processing: 673 treeOutgoing.res 674 treeIncoming[i].res 676 // information related to messages: 677 probe.required 678 new_graft.reserved 679 new_probe.required 680 new_error.failedBW 682 // Local variables: 683 cushion 684 request 686 // PROBE processing: 688 // perform BGP lookup to determine the BgrpNeighbour 690 // test incoming SLA 691 if (no resources in SLA) 692 new_error.failedBW=probe.requiredBW 693 send error message to previous hop 694 exit 695 endif 697 // try to identify the sink tree (DestinationDomain) for the message 698 if (PROBE does not contain a tree id) 699 // perform lookup in NLRI table to find the tree 700 if (tree found) 701 insert tree id in PROBE 702 endif // 703 endif 705 S. Salsano (ed.) Expires November 2002 14 706 //check quiet grafting possibility 707 request = probe.required 708 cushion=treeOutgoing.res-sum(treeIncoming[i].res) 709 if (cushion>=request && tree found) 710 // perform quiet grafting 711 treeIncoming[IN].res += request 712 // send graft message to previous hop 713 new_graft.reserved=request 714 else 715 // quiet grafting is not possible 716 // test outgoing SLA 717 if (no resources in SLA) 718 // send error message to previous hop 719 new_error.failedBW=probe.required 720 else 721 // prepare and forward PROBE message to next hop 722 // update route hop 723 new_probe.required=request 724 endif 725 endif 727 13.2 GRAFT processing 728 // State variables: 729 treeOutgoing.res 730 treeIncoming[IN].res 732 // information related to messages: 733 graft.reserved 734 new_graft.reserved 735 new_error.failedBW 737 // GRAFT processing: 739 // check outgoing SLA and at BGRPP ingress node request intradomain 740 resource 741 if (no resources available) 742 // send error message to previous hop 743 new_error.failedBW= graft.reserved 744 // send refresh message to next hop 745 new_refresh.actualBW=treeOutgoing.res 746 else 747 // update reserved bandwidth 748 treeOutgoing.res += graft.reserved 749 endif 751 // check incoming SLA 752 if (no resources available) 753 // send error message to previous hop 754 new_error.failedBW= graft.reserved 755 else 756 // update reserved bandwidth 758 S. Salsano (ed.) Expires November 2002 15 759 treeIncoming[IN].res += graft.reserved 760 // prepare and forward GRAFT message to previous hop 761 update route hop 762 new_graft.reserved = graft.reserved 763 endif 765 13.3 REFRESH processing 766 // State variables: 767 treeIncoming[IN].res 768 treeOutgoing.res 770 // information related to messages: 771 refresh.actualBW 772 refresh.sender 773 new_refresh.actualBW 775 // REFRESH processing: 777 if(refresh.sender is next hop for tree) 778 // next hop knows more than I 779 if (refresh.actualBW > treeOutgoing.res) 780 error situation 781 //Send to next hop a REFRESH message 782 new_refresh.actualBW=treeOutgoing.res 784 // next hop thinks less than I 785 if (refresh.actualBW < treeOutgoing.res) 786 error situation 787 else 788 // previous hop wants less than I know (like a TEAR) 789 if (refresh.actualBW < treeIncoming[IN].res) 790 treeIncoming.res = refresh.bw 791 // previous hop thinks more than I 792 if (refresh.actualBW > treeIncoming.res) 793 error situation 794 end if 796 13.4 ERROR processing 797 // information related to messages 798 error.failedBW 799 new_error.failedBW 801 // ERROR processing 802 if(this hop is destination) 803 advise intradomain requester 804 else 805 // prepare and forward ERROR message to previous hop 806 // update route hop 807 new_error.failedBW = error.failedBW 809 S. Salsano (ed.) Expires November 2002 16