idnits 2.17.1 draft-bonaventure-bgp-qos-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 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. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 33 has weird spacing: '...tribute allow...' == Line 34 has weird spacing: '...lay and bandw...' == Line 36 has weird spacing: '... decide indep...' == Line 44 has weird spacing: '... can be distr...' == Line 81 has weird spacing: '... length non-t...' == (18 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.) -- 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: 'Empty' is mentioned on line 446, but not defined == Unused Reference: 'CTS00' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'KY00' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RR99' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'SL99' is defined on line 422, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-abarbanel-idr-bgp4-te-00 -- Possible downref: Normative reference to a draft: ref. 'AV00' == Outdated reference: A later version (-02) exists of draft-ietf-diffserv-2836bis-00 == Outdated reference: A later version (-01) exists of draft-parent-obgp-00 -- Possible downref: Normative reference to a draft: ref. 'BPSA01' ** Downref: Normative reference to an Informational RFC: RFC 2519 (ref. 'CS99') ** Obsolete normative reference: RFC 2842 (ref. 'CS00') (Obsoleted by RFC 3392) == Outdated reference: A later version (-01) exists of draft-declercq-bgp-ipsec-vpn-00 -- Possible downref: Normative reference to a draft: ref. 'CTS00' == Outdated reference: A later version (-05) exists of draft-jacquenet-qos-nlri-01 -- Possible downref: Normative reference to a draft: ref. 'Jac00' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-02 ** Obsolete normative reference: RFC 2547 (ref. 'RR99') (Obsoleted by RFC 4364) == Outdated reference: A later version (-09) exists of draft-ramachandra-bgp-ext-communities-08 -- Possible downref: Normative reference to a draft: ref. 'RTR01' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'SL99') Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Olivier Bonaventure 3 INTERNET DRAFT FUNDP 4 February, 2001 5 Expires August, 2001 7 Using BGP to distribute flexible QoS information 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document proposes a flexible QoS attribute that can be used to 33 distribute QoS information with BGP. The proposed attribute allows 34 to associate a set of supported PHB, transit delay and bandwidth 35 information to an UPDATE message. The flexibility of the proposed 36 attribute allows each AS to decide independently which QoS 37 information to redistribute to its peers. 39 1 Introduction 41 In this document, we propose a mechanism to associate QoS 42 information to prefixes that are announced by BGP. Inside a single 43 autonomous system, recent work has focussed on the definition of QoS 44 information that can be distributed by link state routing protocols. 45 In the case of Interior Gateway Protocols (IGP), the focus was the 46 definition of the minimum set of QoS attributes that can be 47 associated to a link to support the QoS or traffic engineering 48 features without overloading the flooding protocol or the route 49 computation [SL99, KY00, KRB^+00]. At the interdomain level, the 50 issue to be considered is different. There are many different 51 autonomous systems on the global Internet with very different 52 requirements and needs in terms of Quality of Service. For example, 53 the autonomous systems that are part of a confederation could want to 54 distribute detailed QoS information inside the confederation while 55 announcing far fewer QoS information on the global Internet. An ISP 56 could also want to provide different types of QoS information to its 57 clients than to other ISPs at public interconnection points. An ISP 58 could want to distribute different QoS information to private peers 59 than to public peers. When dealing with differentiated services, an 60 ISP could want to announce a bandwidth limit on routes associated 61 with the EF PHB while no limit for routes associated with the AF 62 PHB.Many other situations are possible. To support these various 63 requirements, a flexible method to distribute QoS information is 64 necessary for BGP. The solution proposed in this document is equally 65 applicable to the global Internet as well as to BGP-based VPN 66 solutions [RR99, KLV^+00, CTS00].Many complex routing policies, 67 including some related to QoS, can be implemented by using the 68 communities [CTL96] or the extended communities attribute [RTR01]. 69 However, those communities have a local semantics and their 70 utilization must be agreed between each pair of routers. When 71 considering the support of QoS across interdomain boundaries, it 72 would be more useful to have a flexible QoS attribute that can be 73 used for this purpose instead of letting each AS define its private 74 set of communities for almost the same purpose. 76 2 The QoS attribute 78 This document defines a new QoS attribute that can be used to 79 associate QoS information to an UPDATE message. This QoS attribute 80 applies to all NLRI information contained inside the UPDATE message. 81 The QoS attribute is a variable length non-transitive optional 82 attribute. It is encoded as follows : 84 - The attribute flags shall indicate that the QoS attribute is 85 optional, non-transitive and the extended length bit is set to 86 one 87 since the QoS attribute may be longer than 256 bytes. 88 - The attribute type code is to be assigned by IANA 89 - The length of the entire attribute is encoded in two octets 90 - The value of the QoS attribute is encoded as a list of triples : 92 +-------------------------------+ 93 | PHB identification (2 octets) | 94 +------------------+------------+ 95 | QoS Type(1 octet)| 96 +------------------+-----------------------------------+ 97 | QoS value (4 octets) | 98 +------------------------------------------------------+ 100 The QoS type code allows the definition of 256 different types of 101 QoS values. Out of these 256 possible values, value 0 is reserved for 102 future utilization, values 1-127 are to be defined by IANA while 103 values 128-255 are reserved for vendor specific QoS attributes. This 104 document defines QoS types 1-6. 106 2.1 PHB identification 108 The PHB identification is used for two purposes. First, it allows a 109 border router to announce the PHB that it supports. Second, by using 110 the the various QoS values, it is impossible to associate a specific 111 QoS metric to each PHB. The PHB shall be encoded as specified in 112 [BBCF01]. 114 2.2 Empty QoS value 116 This special QoS value shall be used by a border router wishing to 117 announce the support of a specific PHB towards the associated prefix 118 without associating detailed QoS information. The QoS type for this 119 value is 1. In this case, the QoS value field shall be equal to 120 0x00000000. 122 2.3 Maximum Bandwidth 124 The maximum bandwidth QoS value shall be used by a border router to 125 associate a maximum bandwidth to a given PHB. This attribute shall be 126 used by a border router to announce, with eBGP or iBGP, the maximum 127 bandwidth along the path towards the associated prefix. This QoS 128 value differs from the maximum bandwidth community defined in 129 [RTR01] that is only used for iBGP.The maximum bandwidth QoS value is 130 reported in bytes per second and encoded as an IEEE single precision 131 floating point number by using the same format as proposed in 132 [RTR01]. The QoS type field for the maximum bandwidth QoS value is 2. 134 2.4 Available Bandwidth 135 The available bandwidth QoS value shall be used by a border router 136 to announce the available bandwidth associated with an announced 137 prefix. This information shall correspond to the amount of available 138 bandwidth on the path towards the associated prefix.The available 139 bandwidth QoS value is reported in bytes per second and encoded as an 140 IEEE single precision floating point number by using the same format 141 as proposed in [RTR01]. The QoS type field for the maximum bandwidth 142 QoS value is 3.We expect that an information that potentially varies 143 frequently such as the Available Bandwidth will not be distributed 144 through the whole Internet and that filters will be used to limit its 145 distribution. It could for example be used within a confederation or 146 for specific VPN purposes without being re-exported. 148 2.5 Maximum Transit delay 150 This QoS value is used by a border router to associate a maximum 151 transit delay to an announced prefix. This QoS value is an indication 152 of the maximum (one-way) transit delay required to reach the 153 farthest IP address of the associated prefix.The maximum transit 154 delay is reported in units of one microsecond and encoded as an 155 unsigned 32 bits number. The QoS type field of the maximum transit 156 delay QoS value is 4. 158 2.6 Minimum Transit delay 160 This QoS value is used by a border router to associate a minimum 161 transit delay to an announced prefix. This QoS value is an indication 162 of the minimum (one-way) transit delay required to reach the closest 163 IP address of the associated prefix.The minimum transit delay is 164 reported in units of one microsecond and encoded as an unsigned 32 165 bits number. The QoS type field of the minimum transit delay QoS 166 value is 5. 168 2.7 Required signalling 170 This QoS value may be used by a border router to indicate whether 171 or not an explicit signalling operation is required to reach the NLRI 172 included in the UPDATE message. A border router may wish to enforce 173 an explicit signalling operation to be able to perform admission 174 control for example. This QoS value is encoded as a 32 bits field 175 that contains a list of bit flags. Each flag indicates the type of 176 signalling operation required to utilize the route. 178 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Required Signalling | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Bit0 : No explicit signalling required 185 Bit1 : Supports RSVP for Integrated services 186 Bit2 : Supports RSVP for MPLS LSP 187 Bit3 : Supports CR-LDP for MPLS LSP 189 When Bit0 is set (reset), this indicates that the border router 190 sending the UPDATE message is able (refuses) to accept normal IP 191 packet towards the associated NLRI. When Bit1 is set (reset), this 192 indicates that the border router is willing (refuses) to process the 193 establishment of Integrated Services flows with RSVP towards the 194 associated NLRI. When Bit2 is set (reset), this indicates that the 195 border router is willing (refuses) to process MPLS LSP establishment 196 request with RSVP towards the associated NLRI. When Bit3 is set 197 (reset), this indicates that the border router is willing (refuses) 198 to process MPLS LSP establishment request with CR-LDP. The QoS type 199 field of the required signalling QoS value is 6. Additional bit 200 flags may be defined to cover other signalling methods [BPSA01] 202 2.8 Routes without a QoS attribute 204 When a BGP router receives an UPDATE message that does not contain 205 a QoS attribute, it may assume the following defaults : 207 - The set of supported PHB should be set to BE. 208 - The Maximum and Available bandwidth should be set to infinite or 209 the bandwidth of the link from which the UPDATE message is 210 received 211 (if known). 212 - The required signalling flags should indicate that no explicit 213 signalling is required 214 - The Minimum Transit Delay should be set to 0. 215 - The Maximum Transit Delay should be set to infinite. 216 Similar rules apply when the received QoS attribute that not 217 contain a value for each QoS type. 219 3 Aggregation and QoS attributes 220 A key issue for the scalability of the interdomain routing system 221 is the possibility to aggregate routes in a single announcement 222 [CS99]. When QoS information is associated with a prefix, the 223 accuracy of the QoS information may conflict with the need for 224 aggregation. For example, consider the network shown in figure 1. 226 +===========================+ 227 | +---------------+ | 228 | | 12.0.0.0/8 | | 229 | | | | 230 | | EF | | 231 | +---------------+ | 232 | 10msec\ | +---------------+ 233 | \ | | AS10 | 234 | AS20 R|----------|R1 R2| 235 | / |<-------> | AF+EF | 236 | 5msec / | 5msec +---------------+ 237 | +---------------+ | <---------------> 238 | | 13.0.0.0/8 | | 5 msec 239 | | | | 240 | | AF+EF | | 241 | +---------------+ | 242 +===========================+ 244 Figure 1: Simple interdomain topology 246 Assume that in this network, AS20 wants to advertise detailed 247 information about networks 12.0.0.0/8 and 13.0.0.0/8 to AS10. It this 248 case, the border router of AS20 would associate a maximum delay of 10 249 msec and the EF PHB to prefix 12.0.0.0/8. Network 13.0.0.0/8 would be 250 announced with the AF and EF PHB and a maximum delay of 5 msec. Based 251 on this information, AS10 would have to decide how to announce these 252 two prefixes through router R2. If AS10 wants to provide detailed QoS 253 information, then it should announce prefix 12.0.0.0/8 with the EF 254 PHB and a maximum transit delay of 20 msec and prefix 13.0.0.0/8 with 255 both the AF and EF PHB and a maximum transit delay of 15 msec.On the 256 other hand, if AS10 wants to reduce the amount of prefix announced, 257 then it should aggregate 12.0.0.0/8 and 13.0.0.0/8 in a single 258 prefix. In this case, AS10 would announce that network 12.0.0.0/7 259 supports the EF PHB and that the maximum transit delay to reach this 260 network is 20 msec.In many cases, a border router will need to 261 aggregate several specific routes into a single less specific route. 262 This aggregation will inevitably introduce approximation in the route 263 announced. The only way to avoid loosing QoS information is to avoid 264 aggregating routes. However, this solution suffers from scalability 265 problems.Border routers should have the highest flexibility to decide 266 which QoS information should be announced to each peer, possibly on a 267 prefix-by-prefix basis. We believe that it is not possible in such a 268 document to impose strict conditions on how a border router 269 propagates QoS information received from a peer. There are however 270 some guidelines that should be followed in the mechanisms used by a 271 border router to manipulate QoS information : 273 - When redistributing a route, a border router should try, 274 depending 275 on its policy, and whenever possible, to reduce the number of 276 prefixes announced. 277 - When a border router needs to redistribute a route, it may modify 278 the QoS attribute. The border router may add any QoS value 279 associated 280 with one of the PHB identifications explicitly indicated in the 281 received QoS attribute. It cannot add a new PHB to the set of PHB 282 included in the received QoS attribute. The only exception to 283 this 284 rule is when a border router receives an UPDATE message that does 285 not 286 contain the QoS attribute. In this case, this route is implicitly 287 valid for the Best-Effort PHB and thus the border route may add 288 QoS 289 values provided that they are associated with the Best-Effort PHB. 290 - A border router that receives routes with QoS information from a 291 peer and needs to redistribute it is in principle allowed to 292 update 293 or remove any received QoS information. The only exception to this 294 rule is that if a router receives a QoS attribute that does not 295 contain the Best-Effort PHB. In this case, the border router 296 cannot 297 entirely remove the QoS attribute. This implies that in this case 298 the 299 route should not be distributed towards a BGP router that does not 300 support the QoS attribute defined in this document. 301 - When a border router needs to update the maximum (resp. 302 available) 303 bandwidth included in a QoS attribute, it may decrease this 304 maximum 305 (resp. available) bandwidth, but cannot increase it. When 306 updating 307 the bandwidth values, it should ensure that, for each PHB, the 308 maximum bandwidth remains larger than the available bandwidth. 309 - When a border router needs to update the maximum (resp. minimum) 310 transit delay included in a QoS attribute, it may increase this 311 maximum (resp. minimum) transit delay, but cannot increase it. 312 When 313 updating the delay values, it should ensure that, for each PHB, 315 the 316 maximum transit delay remains larger than the minimum transit 317 delay. 319 4 Capability negotiation 321 To advertise the QoS capability to a peer, a BGP speaker uses the 322 BGP Capabilities Advertisement [CS00] This capability is advertised 323 using the Capability code TBD_IANA (to be defined by IANA).The fields 324 in the Capabilities Optional Parameter are set as follows. The 325 Capability Code field is set to TBD_IANA (to be defined by IANA). The 326 Capability Length field is set to 1. The Capability Value contains 327 the version of the QoS attribute. This document defines version 1 of 328 the QoS attribute.To obtain a bi-directional exchange of QoS 329 attributes between a pair of border routers, each border router must 330 advertise to the other the support of the QoS attribute. 332 5 Related work 334 Two extensions to BGP have been proposed recently to advertise QoS 335 information with BGP [AV00, Jac00].In [Jac00], the QoS information is 336 associated to a prefix by defining a new QOS_NLRI attribute. This 337 optional transitive attribute is used to associate QoS information 338 to an announced prefix. This document defines several types of QoS 339 information (reserved bandwidth, available bandwidth, minimum, 340 maximum and average transit delay) and the support of the AF PHB. 341 However, it only allows to associate a single QoS information to each 342 prefix. In contrast, our proposal is to define a flexible QoS 343 attributes that can be manipulated by BGP speakers to support 344 different QoS policies. We expect for example than inside a 345 confederation or for VPN applications, the QoS information will be 346 richer than on the global Internet. The flexibility of our solution 347 allows to easily support these requirements. 348 [AV00] proposes on the other hand to define new optional attributes 349 used to compute TE weights. This document also proposes methods to 350 aggregate these traffic engineering weights. The intended application 351 of [AV00] is to provide a mechanism similar to the BGP Multi Exit 352 Discriminator without being limited to adjacent AS. 354 6 Conclusion 356 In this document, we have a flexible QoS attribute that can be used 357 to distribute QoS information with BGP. The proposed attribute can be 358 used by a BGP speaker to announce the set of PHB that it supports and 359 to optionally associate specific QoS values (minimum and maximum 360 transit delay, available and maximum bandwidth) to each supported 361 PHB. 363 Acknowledgements 365 We would like to thank Christian Jacquenet, Guy Leduc, Stefaan De 366 Cnodder and Steve Uhlig for their very useful comments on this 367 document. This work was partially funded by the European Commission, 368 within the ATRIUM IST project. 370 References 372 [AV00] B. Abarbanel and S. Venkatachalam. Bgp-4 support for traffic 373 engineering. Internet draft, draft-abarbanel-idr-bgp4-te-00.txt, work 374 in progress, May 2000. 376 [BBCF01] D. Black, S. Brim, B. Carpenter, and F. Le Faucheur. Per hop 377 behavior identification codes. Internet draft, draft-ietf- 378 diffserv-2836bis-00.txt, work in progress, January 2001. 380 [BPSA01] M. Blanchet, F. Parent, and B. St-Arnaud. Optical bgp 381 (obgp): Interas lightpath provisioning. Internet draft, draft-parent- 382 obgp-00.txt, work in progress, January 2001. 384 [CS99] E. Chen and J. Stewart. A framework for inter-domain route 385 aggregation. Internet RFC 2519, February 1999. 387 [CS00] R. Chandra and J. Scudder. Capabilities negotiation with 388 BGP-4. Internet RFC2842, May 2000. 390 [CTL96] R. Chandra, P. Traina, and T. Li. BGP communities attribute. 391 Internet RFC 1997, August 1996. 393 [CTS00] J. De Clercq, Y. T'Joens, and P. De Schrijver. BGP/IPsec 394 VPN. Internet draft, draft-declercq-bgp-ipsec-vpn-00.txt, work in 395 progress, July 2000. 397 [Jac00] C. Jacquenet. Providing quality of service indication by the 398 BGP-4 protocol : the QoS_NLRI attribute. Internet draft, draft- 399 jacquenet-qos-nlri-01.txt, work in progress, November 2000. 401 [KLV^+00] K. Kompella, M. Leelanivas, Q. Vohra, J. Achirica, R. 402 Bonica, C. Liljenstolpe, E. Metz, C. Sargor, and V. Srinivasan. 403 MPLS-based Layer 2 VPNs. Internet draft, draft-kompella-mpls- 404 l2vpn-02.txt, work in progress, November 2000. 406 [KRB^+00] K. Kompella, Y. Rekther, A. Banerjee, J. Drake, G. 407 Bernstein, D. Fedyk, E. Mannie, D. Saha, and V. Sharma. IS-IS 408 extensions in support of MPL(ambda)S. Internet draft, draft-kompella- 409 isis-ompls-extensions-00.txt, work in progress, July 2000. 411 [KY00] D. Katz and D. Yeung. Traffic engineering extensions to ospf. 412 Internet draft, draft-katz-yeung-ospf-traffic-02.txt, work in 413 progress, August 2000. 415 [RR99] E. Rosen and Y. Rekhter. BGP/MPLS VPNs. Internet RFC2547, 416 March 1999. 418 [RTR01] S. Ramachandra, D. Tappan, and Y. Rekhter. Bgp extended 419 communities attribute. Internet draft,draft-ramachandra-bgp-ext- 420 communities-08.txt, work in progress, January 2001. 422 [SL99] H. Smit and T. Li. Is-is extensions for traffic engineering. 423 Internet draft, draft-ietf-isis-traffic-01.txt, work in progress, 424 February 1999. 426 A Examples 428 In this appendix, we provide a few examples of the utilization of 429 the QoS attribute. Assume first that AS1 wishes to announce to its 430 peers its ability to support three different PHB : Best-Effort, EF 431 and AF. Assume also that AS1 wishes to announce a maximum bandwidth 432 of 100 Mbps for BE traffic, 10 Mbps for AF traffic and 1 Mbps for EF. 433 In this case, it will send a set QoS attribute composed of : 435 { 436 PHB=BE;QoS-Type=2 [Maximum Bandwidth];MaxBW=100, 437 PHB=AF;QoS-Type=2 [Maximum Bandwidth];MaxBW=10, 438 PHB=EF;QoS-Type=2 [Maximum Bandwidth];MaxBW=1 439 } 441 Assume now that a border router wants to indicate that it supports 442 the BE PHB without associating any QoS information to this PHB. In 443 this case, the QoS attribute would be composed of : 445 { 446 PHB=BE;QoS-Type=1 [Empty] 447 } 448 Assume now a special border router (e.g. a router controlling a 449 label switch router) that is not able to forward IP packets at line 450 rate but is able to support the establishment of label switched 451 paths with RSVP and CR-LDP. Also assume that this router supports AF 452 and BE. In this case, this router should associate the following QoS 453 attribute to each route it is sending to a peer : 455 { 456 PHB=BE;QoS-Type=6 [Required 457 Signalling];[Bit0:Reset,Bit1:Reset,Bit2:Set,Bit3:Set], 458 PHB=AF;QoS-Type=6 [Required 459 Signalling];[Bit0:Reset,Bit1:Reset,Bit2:Set,Bit3:Set] 460 } 462 Another possibility is a border router that provides best-effort 463 service to normal IP packets but is able to provide QoS to label 464 switched paths established by RSVP only. In this case, it could 465 associate the following QoS attribute to routes announced to a peer : 467 { 468 PHB=BE;QoS-Type=6 [Required 469 Signalling];[Bit0:Set,Bit1:Reset,Bit2:Reset,Bit3:Reset] 470 PHB=AF;QoS-Type=6 [Packet switching 471 capability];[Bit0:Set,Bit1:Reset,Bit2:Set,Bit3:Reset] 472 PHB=AF;Qos-Type=2 [Maximum Bandwidth];MaxBW=100 473 PHB=EF;QoS-Type=6 [Packet switching 474 capability];[Bit0:Set,Bit1:Reset,Bit2:Reset,Bit3:Reset] 475 PHB=EF;Qos-Type=2 [Maximum Bandwidth];MaxBW=10 476 PHB=EF;Qos-Type=4 [Minimum Delay];MinTD=10msec 477 PHB=EF;Qos-Type=5 [Maximum Delay];MaxTD=100msec 478 } 480 This QoS information indicates that the border router supports the 481 BE, AF and EF PHB. For the BE PHB, there are no specified QoS 482 values. For the AF PHB, a LSP must be established before actual 483 traffic can flow and the maximum reservable bandwidth is 100 Mbps. 484 For the EF PHB, a LSP must also be established before actual traffic 485 can flow and the transit delay is expected to be between 10 and 100 486 msec. The maximum bandwidth reservable for EF is set to 10 Mbps. 488 Author's Address 490 Olivier Bonaventure 491 Infonet group 492 Institut d'Informatique 493 Facultes Universitaires Notre-Dame de la Paix 494 Rue Grandgagnage 21, B-5000 Namur, Belgium. 495 E-mail: Olivier.Bonaventure@info.fundp.ac.be 496 URL : http://www.infonet.fundp.ac.be