idnits 2.17.1 draft-iab-rtrws-over-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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 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) ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) ** Downref: Normative reference to an Historic RFC: RFC 2201 (ref. '2') -- Unexpected draft version: The latest known version of draft-ietf-diffserv-arch is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-diffserv-arch (ref. '3') ** Obsolete normative reference: RFC 2117 (ref. '4') (Obsoleted by RFC 2362) ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '8') -- Unexpected draft version: The latest known version of draft-ietf-diffserv-header is -03, but you're referring to -04. -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Architecture Board Steve Deering 2 INTERNET DRAFT Cisco Systems 3 15 February 1999 Sue Hares 4 Merit Networks 5 Charles E. Perkins 6 Radia Perlman 7 Sun Microsystems 9 Overview of the 1998 IAB Routing Workshop 10 draft-iab-rtrws-over-01.txt 12 Status of This Memo 14 This document is a submission by the Internet Architecture Board 15 Working Group of the Internet Engineering Task Force (IETF). 16 Comments should be submitted to the 17 iab-routing-workshop@external.cisco.com mailing list. 19 Distribution of this memo is unlimited. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at 29 any time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document is an overview of a Routing workshop held by the 42 Internet Architecture Board during March 25-27, 1998. The major 43 points of discussion are listed, along with some conclusions and 44 action items for many of the points of discussion. The full body of 45 the report will be provided in a separate document. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 2 55 2. Conclusions and Action Items 3 56 2.1. Scaling of Unicast Routing and Addressing . . . . . . . . 3 57 2.1.1. Unicast Routing - Conclusions . . . . . . . . . . 3 58 2.1.2. Unicast Routing - Action Items . . . . . . . . . 3 59 2.2. Levels of Addressing of Addressing and Routing . . . . . 4 60 2.3. Network Address Translation (NAT) devices . . . . . . . . 4 61 2.3.1. NAT devices - Conclusions . . . . . . . . . . . . 4 62 2.3.2. NAT devices - Action Items . . . . . . . . . . . 4 63 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.4.1. Multicast - Conclusions . . . . . . . . . . . . . 4 65 2.4.2. Multicast - Action Items . . . . . . . . . . . . 6 66 2.5. Routing Stability . . . . . . . . . . . . . . . . . . . . 6 67 2.5.1. Routing Stability - Conclusions . . . . . . . . . 6 68 2.5.2. Routing Stability - Action Items . . . . . . . . 6 69 2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.6.1. ToS/CoS/QoS - Action Items . . . . . . . . . . . 7 71 2.7. Routing Protocol Security . . . . . . . . . . . . . . . . 7 72 2.7.1. Routing Security - Conclusions . . . . . . . . . 7 73 2.7.2. Routing Security - Action Items . . . . . . . . . 8 74 2.8. Routing Policy . . . . . . . . . . . . . . . . . . . . . 8 75 2.8.1. Routing Policy - Conclusions . . . . . . . . . . 8 76 2.8.2. Routing Policy - Action Item . . . . . . . . . . 8 77 2.9. Network to Host Flow of Information . . . . . . . . . . . 8 78 2.9.1. Host Information - Conclusions . . . . . . . . . 8 79 2.9.2. Host Information - Action Items . . . . . . . . . 9 80 2.10. Shorter Topics . . . . . . . . . . . . . . . . . . . . . 9 81 2.10.1. Multi-strand Trunking . . . . . . . . . . . . . . 9 82 2.10.2. Routing Diagnostic and Development Tools . . . . 9 83 2.10.3. Anycast . . . . . . . . . . . . . . . . . . . . . 10 84 2.10.4. Load Sensitive IGP routing for Best Effort Traffic 10 85 2.10.5. Geographical Addresses and Renumbering . . . . . 11 87 3. Summary of Action items 11 88 3.1. Action Items for the IAB . . . . . . . . . . . . . . . . 11 89 3.2. Action Items for IETF Working Group Chairs . . . . . . . 11 90 3.3. Action Items for the IRTF Routing Research Group . . . . 11 92 A. Participants 13 94 1. Introduction 96 From March 25 to March 27, 1998 the Internet Architecture Board 97 (IAB) held a workshop on Routing. The workshop focused on current 98 problems within the Internet and the long term solutions that should 99 be addressed. This document summarizes the discussions the group 100 had on routing, and lists the conclusions reached by the workshop. 101 Section 2 lists the conclusions reached by the participants of the 102 workshop and the suggestions for additional work or redirection of 103 current work. Sections 2.1-2.10 attempt to extract the major points 104 of what was, in actuality, many multifaceted discussions, sometimes 105 occuring all at the same time. Appendix A contains a list of the 106 participants who attended the workshop. 108 The topics covered at length during the IAB workshop were: 110 1. Scaling of Unicast Routing and Addressing (section 2.1) 111 2. Unicast Addressing Issues (Section 2.2) 112 3. The Effect of extending IP version 4 in the Internet by using 113 Network Address Transformation boxes (Section 2.3) 114 4. Multicast Routing (Section 2.4) 115 5. Routing Instability (Section 2.5) 116 6. Quality of Service Routing (Section 2.6) 117 7. Routing Security (Section 2.7) 118 8. BGP Policy (Section 2.8) 119 9. Flows of information from network routing to hosts for improved 120 services (Section 2.9) 122 In addition the following topics were briefly covered: 124 a. Multi-strand trunking 125 b. Better tools for monitoring and diagnosis of network problems 126 c. Routing protocol bandwidth minimization 127 d. Automatic renumbering and automatic organization 128 e. Anycast 129 f. Load-sensitive routing 130 g. Geographical addressing 132 These shorter topics are contained in section 2.10. 134 It would be unrealistic to assume that the workshop had definitive 135 answers to all the technical problems that were raised. The best 136 that can be hoped is that we raised most of the relevant issues and 137 gave opinions that were the best guess of the people at the meeting, 138 keeping in mind that the attendees did not come armed with data to 139 back up opinions. Much of the discussion amounted to an exploration 140 of the intuition of the experts in attendance, intuition gained 141 after years of experience in making the Internet work. More work is 142 needed to validate the intuition and experience by way of scientific 143 experimentation and analysis. Unfortunately, it's not so easy to 144 find a spare collection of global Internets upon which one might 145 perform controlled experiments. 147 2. Conclusions and Action Items 149 The participants came to a number of conclusions after the 150 discussions described in sections 2.1-2.10. These conclusions, 151 presented in this document, provide summary statements and action 152 items for the IETF community. 154 2.1. Scaling of Unicast Routing and Addressing 156 2.1.1. Unicast Routing - Conclusions 158 The participants of the workshop came to the following conclusions 160 1. Most of the current unicast scaling problems can be fixed with 161 improved implementation. 163 2. Some long term systemic issues that may eventually overwhelm the 164 unicast routing are: 166 - Flaps - which will only get worse unless work is undertaken 167 - Multi-homing 169 3. We'd like more research into what's breaking; not just more data, 170 but more analysis of the data 172 The group reviewed the following potential solutions: 174 - Architected NAT (improving the existing Network Address 175 Translation schemes to provide better scaling) 176 - IPv6 (deploying an IP version 6 infrastructure) 177 - MAP/Encap (map to aggregatable addresses and encapsulate the 178 original packet) 179 - Do nothing 180 - Aggressive renumbering (try to continue to encourage renumbering 181 to improve utilization of the IP version 4 address space) 182 - Metro addressing (use a geographical or metropolitan based 183 addressing scheme) 185 2.1.2. Unicast Routing - Action Items 187 We recommend that the IRTF Routing Research group should encourage 188 more analysis of routing data, not just the collection of more data. 190 2.2. Levels of Addressing of Addressing and Routing 192 Levels of hierarchy do not matter to the customers. Address 193 hierarchy must be distinguished from routing hierarchy. The group 194 examined whether the current Internet has enough levels of hierarchy 195 in Internet addresses or routing infrastructure. The group did not 196 find that levels of hierarchy should be added to the Internet, at 197 least for now. Flat routing at the AS level seems to be workable; 198 if this changes in the future, hierarchy would need to be revisited, 199 and studied with due consideration to convergence time for routing 200 algorithms and trust management. There is no universal agreement 201 that adding levels of hierarchy provides a well-defined benefit. 202 Furthermore, two levels is difficult for most people, and any more 203 than that is difficult both to build and to use. 205 2.3. Network Address Translation (NAT) devices 207 2.3.1. NAT devices - Conclusions 209 Upon reviewing the NATs, the group 211 1. Noted that NAT devices are fairly widely deployed 212 2. Identified various issues about the use of NAT devices within the 213 internet 214 3. Discussed the interaction between NAT devices and applications 215 4. Listed the following options regarding NAT devices: 216 - Eliminate NATs 217 - Fix NATs to interact better with the rest of the Internet 218 - Fix applications to interact better with NAT boxes 219 - Don't do certain things -- like IP Security (IPSec) 221 2.3.2. NAT devices - Action Items 223 1. Forward our concerns, problems and suggestions to the appropriate 224 working groups 225 2. Note architectural work outside the NAT working group 226 3. Suggest to the IAB that it continue to be concerned about the 227 issues involving NATs 229 2.4. Multicast 231 2.4.1. Multicast - Conclusions 233 Since the multicast model was created, many multicast applications 234 have been tried over the Internet multicast routing fabric. The 235 group began to discuss the multicast model in terms of enabling 236 multicast applications to run efficiently, and scale favorably with 237 future growth. Multicast applications place varying requirements on 238 multicast routing. 240 Multicast applications may have a variable: 242 - number of sources, 243 - number of receivers, 244 - amount of data, 245 - amount of data in a burst, and length of quiet periods 246 - number of groups utilized per application or per group of 247 cooperating applications, 248 - amount of time during which the group exists, and 249 - topological distance between members of the group. 250 - volatility of membership 252 Multicast routing must provide the flexibility to support the 253 varying requirements of different multicast applications. The 254 current multicast model establishes multicast routing paths upon 255 reception of a data packet. The discussion on the viability of the 256 multicast model examined the viability of the model in terms of the 257 uses of multicast routing by applications and the scalability to 258 full Internet usage. The current multicast model was examined to 259 determine if the model is still viable for the Internet today. For 260 example, providing for many groups of small conferences (few people 261 to few remote people) with global topological scope scales badly 262 given the current multicast model. 264 The group felt the existing multicast protocols and multicast should 265 be evaluated in terms of the requirements listed above. The group 266 suggested that the evaluation should include the multicast protocols 267 DVMRP [5], MOSPF [8], PIM [4], CBT [2], and Express (an unpublished 268 single-source multicast model proposed by Hugh Holbrook and David 269 Cheriton), as well as the following mechanisms used by multicast 270 applications: 272 1. Registering with the core or the RP (Rendezvous Point), 273 2. Having the ID of the group include the core, and having joins 274 specify the core 275 3. Having the ID of the group include the core, and having joins and 276 data specify both 277 4. Sending data via unicast to all members, and 278 5. Sending data via unicast transport to the RP. 280 The group acknowledged that the current multicast model does not 281 scale well for all scenarios that applications use. 283 The group noted that reliable multicast is surprisingly orthogonal to 284 the issues about the scaling of the multicast model to all possible 285 applications. 287 2.4.2. Multicast - Action Items 289 Encourage evaluation and written reports on these multicast 290 protocols, and mechanisms for different types of protocols. 292 Notify the IRTF Routing Research Group of the need to charter 293 activity in this area. 295 2.5. Routing Stability 297 2.5.1. Routing Stability - Conclusions 299 Damping the effects of route updates enhances stability, but possibly 300 at the cost of reachability for some prefixes. A prefix can be 301 damped and reachable via another path, so that for such prefixes the 302 effects of damping are less serious than for other prefixes. The 303 performance of various algorithms for enhancing stability should 304 be measured by recording whether the affected route prefixes are 305 reachable or not reachable. Using current damping approaches, 306 approximately 1% of the prefixes are affected at any one point in 307 time. We should try to find out how many prefixes are unreachable 308 because of damping. 310 2.5.2. Routing Stability - Action Items 312 The conclusion is that this effort merits continued investigation. 314 The IRTF Routing Research Group should measure how stable things are, 315 and if stability is an issue, to study methods of making them more 316 stable. 318 2.6. ToS/CoS/QoS 320 The group noted that the terms Type of Service (ToS), Class of 321 Service (CoS), and Quality of Service (QoS) are imprecise as 322 currently used. The discussion started by defining the terminology 323 as follows: 325 ToS: hop by hop routing based on destination plus ToS bits [9] 326 CoS: classes of service based on service contracts. These classes 327 of service are enabled by a variety of mechanisms which include 328 queueing, and multiple physical or link level paths. 329 QoS: managing routes that meet certain quality of service constraints, 330 and involving the following steps: 331 * routing the resource requests 332 * setting up a path that satisfies the constraints 333 * routing the data 335 There is no smooth dividing line between between ToS and QoS. ToS is 336 relative. QoS is absolute. The group discussed whether there is a 337 demand for ToS, CoS and QoS. Differentiated-services [3] as discussed 338 in the IETF is ToS++. 340 The group also discussed a more general concept of "Constraint 341 Based Routing" which was defined as traffic engineering on massive 342 flows. Constraint based routing allows the providers to utilize 343 the bandwidth in their network to handle traffic requests from 344 users. Besides enabling policy management techniques, constraint 345 based routing allows providers to route traffic based on the 346 characteristics of the traffic flows. 348 2.6.1. ToS/CoS/QoS - Action Items 350 We recommend that IETF should look into the issue of Constraint Based 351 Routing. 353 2.7. Routing Protocol Security 355 2.7.1. Routing Security - Conclusions 357 After a lengthy discussion of the various problems of network 358 security, the group notes that: 360 1. Routers need intrinsic system security as good as or better than 361 any host computer. 362 2. Improving router security will not solve all problems. 363 3. Console access to the router can do everything. 364 4. One compromised router can create disaster. 365 5. ISPs and vendors should consider taking some control traffic out 366 of band, due to lack of wire speed authentication. 367 6. We discussed other issues that will be passed on to the 368 appropriate people involved with network security. 369 7. Identified areas of work to improve things (e.g., wire speed 370 authentication). 372 2.7.2. Routing Security - Action Items 374 The IETF should encourage work on "wire speed" authentication, 375 pair-wise authentication of routers in routing protocols, and 376 Byzantine robustness [6] in routing protocols. 378 2.8. Routing Policy 380 2.8.1. Routing Policy - Conclusions 382 During our discussion on routing policy the group reviewed what could 383 be done with BGP. The group noted that: 385 1. Some routing policies requested by ISPs or NSPs are not solvable 386 with BGP. Some of these "unsolvable" routing policies can be put 387 into effect using tunnels and static configuration. 388 2. BGP is only a mechanism for announcing reachability 389 3. BGP routing controls traffic direction without regard to traffic 390 volume. 391 4. BGP policy management is too delicate, too easy to mess up, and 392 fragile. 393 5. Router Configuration Language is very complex and error-prone 394 6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise nets 395 should deal with it. 397 The group concluded the Internet needed a better routing policy 398 specification language. 400 2.8.2. Routing Policy - Action Item 402 Pass the concerns about the Routing Policy Syntax Language (RPSL) [1] 403 to chairs of the Routing Policy Syntax (RPS) working group [11]. 405 2.9. Network to Host Flow of Information 407 2.9.1. Host Information - Conclusions 409 Publishing information about traffic statistics along infrastructure 410 routes could improve the way Internet services replicate data for 411 retrieval from various sites. This replication could be especially 412 important for the retrieval of information off the web. Currently, 413 web pages refer people to caches local to their sites; for instance, 414 a European site might be used for United Kingdom customers and a US 415 site for North American customers. Proponents of web caches want to 416 auto-configure the locations of web caches so a user's web browser 417 can automatically discover the local cache. Other applications share 418 this need for finding the best cache for a particular service. 420 2.9.2. Host Information - Action Items 422 The group recommends a BOF be held on Measuring Path Characteristics. 423 Measurement of path characteristics should include: 425 - format for exchange of measurement data 426 - mechanisms for distribution of measurement data 428 IPPM working group [7] is dealing with issues within the measurement 429 problem space. 431 2.10. Shorter Topics 433 2.10.1. Multi-strand Trunking 435 PPP did multi-link in a way that required too much computation and 436 could not be used for faster links. Internet technology should 437 treat multiple parallel trunks as 1 link at the IP layer, but with 438 multi-dimensional metrics. 440 Multi-strand Trunking - Action Items 442 There is design and development work at layer two which should be 443 done to support the multiple parallel trunks. This layer two work 444 is outside the scope of the IETF. Layer three routing should support 445 richer metrics in OSPF. 447 2.10.2. Routing Diagnostic and Development Tools 449 2.10.2.1. Routing Diagnostics - Conclusions 451 1. It would be nice to have an Authoritative Database listing those 452 prefixes permitted from each AS. The authoritative data base was 453 attempted before without success, but the group felt it might be 454 useful to try again. 455 2. SNMP version 3 should be deployed in order to make use of its 456 improved authentication, scope and rate limiting 457 3. Remotely-controlled traffic monitors should be used to measure 458 traffic 459 4. Better tools are needed for preventative problem detection 461 2.10.2.2. Routing Diagnostics - Action Items 463 1. Encouraged an authoritative database within the Internet 464 2. Notify SNMP version 3 working groups regarding needs for 465 authentication, scope, and rate limiting. 466 3. Encourage funding of better tools for remotely controlled traffic 467 sources and pro-active problem detection. 469 2.10.3. Anycast 471 2.10.3.1. Anycast - Conclusions 473 1. We need to describe the advantages and disadvantages of anycast. 474 2. Local-scoped well-known anycast addresses will be useful to 475 applications. 477 2.10.3.2. Anycast - Action Items 479 A BOF should be held to plan work on anycast. 481 If a working group forms, a paper on the advantages and disadvantages 482 of anycast should be included as part of the charter. 484 2.10.4. Load Sensitive IGP routing for Best Effort Traffic 486 2.10.4.1. Load Sensitive IGP - Conclusions 488 While load sensitive routing is interesting in some ways, it cannot 489 be considered until certain problems are worked out. Currently, 490 constraint based routing is assigning administrative metrics to allow 491 routing to adapt to different traffic patterns. Load sensitive 492 routing may increase oscillation and instability of routes. This 493 instability of routes, sometimes called churn, may affect the ability 494 of the routing infrastructure to scale. 496 Load sensitive routing would allow IGPs to better utilize links. 497 Past and current efforts in load sensitive routing include: QoS 498 OSPF [10], Q-OSPF [10], and load sensitive routers developed by BBN. 500 2.10.4.2. Load Sensitive IGP - Action items 502 The IRTF Routing Research group chair and Routing Area Director 503 should discuss this subject and determine what techniques from 504 Load Sensitive IGP routing are ready for IETF, and what requires 505 additional research. 507 2.10.5. Geographical Addresses and Renumbering 509 This topic was discussed, but without any conclusions or action 510 items. 512 3. Summary of Action items 514 3.1. Action Items for the IAB 516 1. The IAB should be concerned about the issues involving NATs 517 2. Authoritative Database (for addresses within domains) should be 518 encouraged within the Internet 519 3. Encourage funding of better tools for remotely controlled traffic 520 sources and pro-active problem detection. 522 3.2. Action Items for IETF Working Group Chairs 524 1. NAT: Forward our concerns, problems and suggestions to the 525 appropriate working groups 526 2. We recommend that IETF should work the issue of Constraint Based 527 Routing. 528 3. The IETF should encourage work on "wire speed" authentication, 529 pair-wise authentication of routers in routing protocols, and 530 Byzantine robustness in routing protocols. 531 4. Concerns about the Routing Policy Specification Language (RPSL) 532 should go to the Routing Policy Systems (RPS) working group 533 chair. 534 5. The group recommends a BOF be held on Measuring Path 535 Characteristics. The BOF should consider the data exchange 536 format of measurement and mechanisms to distribution of data 537 mechanism. It is noted that the IPPM working group is dealing 538 with issues within the measurement problem space. 539 6. There is layer two work which should be done to support the 540 multiple parallel trunks which is outside the scope of the IETF. 541 Layer three routing should support richer metrics in OSPF. 542 7. SNMP version 3 working groups should be notified about the issues 543 about authentication, scope, and rate limiting. 544 8. A BOF should be held to plan work on anycast. A document on 545 anycast should be part of the proposed working group charter. 547 3.3. Action Items for the IRTF Routing Research Group 549 1. We recommend that the IRTF Routing Research working group try to 550 encourage more analysis of routing data, not just the collection 551 of more data. 553 2. Encourage evaluation and written reports on the evaluation of 554 these multicast protocols and mechanisms for different types of 555 protocols 557 3. The IRTF Routing Research group chair and the Routing Area 558 Director should discuss Load Sensitive IGP routing and determine 559 whether it is ready for the IETF. 561 A. Participants 563 Harald Alvestrand Harald.Alvestrand@maxware.no, 564 Fred Baker fred@cisco.com, 565 Jeff Burgan burgan@corp.home.net, 566 Brian Carpenter brian@hursley.ibm.com, 567 Noel Chiappa jnc@ginger.lcs.mit.edu, 568 Rob Coltun rcoltun@fore.com, 569 Steve Deering deering@cisco.com, 570 Deborah Estrin estrin@usc.edu, 571 Dino Farinacci dino@cisco.com, 572 Paul Francis francis@slab.ntt.co.jp, 573 Elise Gerich epg@home.net, 574 Joel Halpern jhalpern@newbridge.com, 575 Sue Hares skh@merit.edu, 576 Cyndi Jung cmj@3Com.com, 577 Dave Katz dkatz@jnx.com, 578 Tony Li tli@juniper.net, 579 Peter Lothberg roll@stupi.se, 580 Louis Mamakos louie@uu.net, 581 Dave Meyer dmm@cisco.com, 582 Keith Moore moore@cs.utk.edu, 583 Bob Moskowitz rgm@htt-consult.com, 584 Thomas Narten narten@raleigh.ibm.com, 585 Vern Paxson vern@ee.lbl.gov, 586 Charlie Perkins Charles.Perkins@Eng.Sun.COM, 587 Radia Perlman Radia.Perlman@East.Sun.COM, 588 Yakov Rekhter yakov@cisco.com, 589 Allyn Romanow allyn@MCI.NET, 590 Martha Steenstrup msteenst@bbn.com, 591 George Swallow swallow@cisco.com, 593 References 595 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 596 M. Terpstra, and C. Villamizar. Routing policy specification 597 language (RPSL). Request for Comments (Proposed Standard) 2280, 598 Internet Engineering Task Force, January 1998. 600 [2] T. Ballardie. Core based trees (CBT) multicast routing 601 architecture. Request for Comments (Experimental) 2201, 602 Internet Engineering Task Force, September 1997. 604 [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 605 W. Weiss. An Architecture for Differentiated Services. 606 draft-ietf-diffserv-arch-02.txt, October 1998. (work in 607 progress). 609 [4] S. Deering. Protocol independent multicast-sparse mode 610 (PIM-SM): protocol specification. Request for Comments 611 (Experimental) 2117, Internet Engineering Task Force, June 1997. 613 [5] S. Deering, C. Partridge, and D. Waitzman. Distance vector 614 multicast routing protocol. Request for Comments (Experimental) 615 1075, Internet Engineering Task Force, November 1988. 617 [6] Charlie Kaufman, Radia Perlman, and Mike Speciner. Network 618 Security: Private Communication in a Public World, pages 619 462--465. Prentice-Hall, Inc., 1995. 621 [7] W. Leland and M. Zekauskas (chairs). IP Performance Metrics 622 (IPPM), October 1997. 623 http://www.ietf.org/html.charters/ippm-charter.html. 625 [8] J. Moy. Multicast extensions to OSPF. Request for Comments 626 (Proposed Standard) 1584, Internet Engineering Task Force, March 627 1994. 629 [9] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of 630 the Differentiated Services Field (DS Field) in the IPv4 and 631 IPv6 Headers. draft-ietf-diffserv-header-04.txt, October 1998. 632 (work in progress). 634 [10] H. Sandick and E. Crawley (chairs). QoS Routing (qosr), April 635 1997. http://www.ietf.org/html.charters/qosr-charter.html. 637 [11] C. Villamizar and C. Alaettinoglu (chairs). Routing Policy 638 Syntax (RPS), July 1995. 639 http://www.ietf.org/html.charters/rps-charter.html. 641 Author's Addresses 643 Questions about this memo can be directed to: 645 Stephen E. Deering Susan Hares 646 Cisco Systems, Inc. Merit, Inc. 647 170 West Tasman Drive 1071 Beal Avenue, 648 San Jose, CA 95134-1706 Ann Arbor, MI 48109 649 USA USA 651 Phone: +1 408 527-8213 Phone: +1 313 936-2095 652 EMail: deering@cisco.com EMail: skh@merit.edu 654 Radia Perlman Charles E. Perkins 655 Sun Microsystems Laboratories Sun Microsystems Laboratories 656 2 Elizabeth Drive 15 Network Circle 657 Chelmsford, MA 01824 Menlo Park, CA 94025 658 USA USA 660 Phone: +1 978 442-3252 Phone: +1 650 786-6464 661 EMail: Radia.Perlman@sun.com EMail: cperkins@eng.sun.com 662 Fax: +1 650 786-6445