idnits 2.17.1 draft-ietf-cdi-request-routing-reqs-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. == 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 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([MODEL], [ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 431: '...outing protocols MUST use an administr...' RFC 2119 keyword, line 434: '...outing protocols SHOULD support arbitr...' RFC 2119 keyword, line 437: '...outing protocols MUST treat other cont...' RFC 2119 keyword, line 441: '...outing protocols MUST support methods ...' RFC 2119 keyword, line 444: '...outing protocols SHOULD be compatible ...' (49 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - Request-routing protocol MUST not preclude request-routing systems from implementing policy based routing decisions. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'KNOWN MECH' is defined on line 666, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-model (ref. 'MODEL') == Outdated reference: A later version (-03) exists of draft-ietf-cdi-known-request-routing-01 ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-known-request-routing (ref. 'KNOWN MECH') == Outdated reference: A later version (-01) exists of draft-ietf-cdi-architecture-00 -- Possible downref: Normative reference to a draft: ref. 'ARCH' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft B. Cain 3 Storigen Systems 4 O. Spatscheck 5 AT&T Labs 6 M. May 7 Activia Networks 8 A. Barbir 9 Nortel Networks 10 June 2002 12 Request-Routing Requirements for Content Internetworking 13 draft-ietf-cdi-request-routing-reqs-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2000). All Rights Reserved. 39 Abstract 41 Request-routing systems (RRS) are components of Content Distribution 42 Networks (CDNs) that direct client requests to an available copy of 43 content based on one or more metrics. To enable the interconnection of 44 CDNs [MODEL][ARCH], it is necessary for their request-routing systems to 45 interconnect and exchange information such that client requests can be 46 routed between CDNs. This is called request-routing internetworking. 47 This document specifies the requirements for request-routing 48 internetworking. 50 1. Introduction 52 Request-routing systems (RRS) are components of Content Distribution 53 Networks (CDNs) that direct client requests to an available copy of 54 content based on one or more metrics. To enable the interconnection 55 of CDNs [MODEL][ARCH], it is necessary for their request-routing 56 systems to interconnect and exchange information such that client 57 requests can be routed between CDNs. This is called request-routing 58 internetworking. This document specifies the requirements for 59 request-routing internetworking. 61 1.1 Document Organization 63 This document is organized as follows. Section 1 presents an 64 introduction to request-routing systems. Section 2 presents the 65 details of request-routing system components and protocols. Section 66 3 presents detailed requirements for each component, sub-component or 67 protocol from sections 1 and 2. 69 1.2 Overview of Request-Routing Systems 71 Request-routing systems (RRS) are components of content networks (CN) 72 that direct client requests to surrogates that can "best" service the 73 request [KNOWN_MECH]. Request-routing decisions are based on a set 74 of metrics that may include for example network proximity and server 75 load. The basic functionality of a request-routing system can be 76 summarized by the following: 78 1. It directs clients to surrogates that are able to service their 79 requests. 81 2. It directs clients to surrogates that (per a set of metrics) are 82 able to provide the "best" service. 84 A given client request may not necessarily cause a full redirection 85 but may use cached information to fulfull the request (e.g. DNS-based 86 request- routing systems). Nonetheless, we use the term "client 87 request" within this document to refer (mostly) to a request not 88 fulfilled from an intermediate cache. 90 For the sake of clarity, we now reiterate several important 91 assumptions from [ARCH] [MODEL]: 93 1. Each content network is a "black box" to other networks to which 94 it is interconnected. We use the term "neighbor CN" to refer to a 95 directly interconnected content network. 97 2. Content is served by surrogates that act on behalf of an origin 98 server that holds the "master" or "authoritative" copy of content. 99 Surrogates are part of a distribution system. 101 3. A request-routing system is responsible for directing/servicing 102 requests for one or more distribution systems. 104 4. Each distribution system may have its own internal (or intra-CN) 105 request-routing system that is not exposed to other interconnected 106 networks. 108 5. Request-routing systems interconnect through content 109 internetworking gateways (CIG) that implement standards based 110 interconnection protocols. A CN's CIG is the only "visible" 111 element to other interconnected CNs. 113 1.3 Generic Request-Routing System Architecture 115 This section presents a generic architecture of a request-routing 116 system to assist in understanding request-routing systems as well as 117 the requirements for their interconnection. In Figure 1, a 118 conceptual view of a request-routing system is presented; it consists 119 of the following components: Content Topology Exchange, Content 120 Topology Database and Route Computation. A brief summary of these 121 components is provided below: 123 ____________________________________________ 124 | ___________ ________ ________ | 125 | |Routing | |Content | |Advert- | | Request-Routing 126 | |Computation|<-|Topology|<->| ment | |<->Information 127 | |___________| |Database| |Exchange| | Exchange 128 | |________| |________| | Protocol 129 |__________________________________________| 131 Figure 1. 133 1. Routing Computation: The computation of the best surrogate for a 134 given set of clients based on information stored in the Content 135 Topology DataBase, route computing algorithm, and configured 136 policies. 138 2. Content Topology Database: The topology database includes 139 detailed advertisement information received from CN neighbors and 140 the associated metrics that are included. 142 3. Advertisement Exchange: This functional block is responsible for 143 implementing the Request-Routing Information Exchange protocol. 145 4. Request-Routing Information Exchange Protocol: The actual 146 protocol used to exchange sets of content advertisements and area 147 advertisements [MODEL]. 149 1.4 Interconnecting Request-Routing Systems 151 Within a single CN, a request-routing system is used to direct client 152 requests to surrogates that are part of its own distribution system. 154 However, when request-routing systems are interconnected, a request- 155 router has the ability to redirect client requests to neighbor CNs. 156 That is, when neighbor CN can "better" serve a set of clients, it may 157 be desirable to direct requests to that neighbor CN. In order to 158 determine which CN may best serve a client request, one or more 159 protocols may be required to exchange various types of information 160 and associated metrics. 162 This document describes the components of request-routing systems and 163 requirements for interconnecting them. 165 2. Overview of Request-Routing System Components and Protocols 167 This section provides a detailed description of the basic components 168 of a request-routing system. Section 3 provides a description of the 169 specific requirements for each component. 171 2.1 Request-Routing System Types 173 The methods in which a client request is directed may be different 174 depending on the architecture of the request-routing system. 175 Currently, there are two well-known types of request-routing systems 176 [KNOWN_MECH]. These two types are described below: 178 1. DNS-based Request-Routing Systems: The Domain Name System (DNS) 179 is used for the direction of client requests. In this approach, 180 one or more domain names are assigned to the request-routing 181 system; these names are then used as part of a URI reference to 182 direct client requests. The limitations of DNS-based systems are 183 described [KNOWN_MECH] and in section 2.1.1. 185 2. "In-Line" Request-Routing Systems: These request-routing 186 systems are "in-line" to client requests. Examples of in-line 187 request-routing systems are those that may be implemented within a 188 proxy or a layer-7 router. In-line request-routing systems have 189 full visibility into content requests (e.g. full URL) as well as 190 visibility of the client's IP address [note: this isn't always true 191 if transparent proxies are in place]. 193 The distinction between these request-routing system types is 194 important because of the differences in: 196 - The view of the content identifier (partial vs. whole). 198 - The view of the client (e.g. client's IP vs. client's local DNS). 200 - The implementation requirements of the two types (e.g. DNS 201 caching). 203 2.1.1 DNS-Based Request-Routing Systems 204 In DNS-based request-routing systems [ARCH, KNOWN_MECH], only 205 aggregate sets of content may be "directed" because a domain name 206 (e.g. images.blah.com) can only (reasonably) represent a larger set 207 of content. A DNS-based request-routing system works well in 208 scenarios where many surrogates share large sets of content. 210 DNS-based request-routing systems suffer from the following 211 limitations: 212 - The request-routing system knows only the domain name of the 213 requested content. This precludes the RRS from knowing the full 214 content path (e.g. URI) and the content type (e.g. HTTP, RTSP). 216 - The request-routing system knows the client's local DNS server, 217 not the client itself. 219 - The request-routing system responses may be cached in DNS 220 servers. The result is that a client request may not be 221 individually directed by the request-routing system. 223 2.1.1.1 DNS Example 225 Content network CN-A is authoritative for http://images.blah.com (or 226 CNAMEs are used to ultimately force a resolution of this name to CN 227 A). Assume that DNS-based request-router R is part of CN-A and is 228 also a CIG for CN-A. When R receives a client DNS request for 229 images.blah.com, it makes a request-routing decision. This decision 230 may be to direct the request to its own surrogates or to direct the 231 request to another CN. This decision is based on the routing 232 computation by CIG-A that in turn is based on "area" and/or "content" 233 advertisements [MODEL] received from neighbors. For example, CIG-A 234 can make a request-routing decision based on the following: 236 1. Information contained in area advertisements that have been 237 received from interconnected CNs. An example may be an IP prefix 238 advertised with an associated metric. 240 2. The ability of interconnected CNs to support the (content) type 241 of the request. 243 3. Information contained in content advertisements that may 244 include: content metrics, availability of content, etc. With DNS- 245 based request-routing systems, content specific information is only 246 relevant to the DNS name (e.g. in a URI). 248 4. Local request-routing policy. 250 If the choice is made to direct the request to another CN, the 251 appropriate CNAME is used to direct the client's DNS to the chosen 252 neighbor CN. The process then continues. 254 2.1.2 "In-Line" Request-Routing Systems 255 A Layer-7 router or Proxy situated close to a client may be used as 256 an "in-line" request-routing system. Such a RRS is capable of 257 directing client requests based on individual full content requests. 258 This is possible because layer-7 information (e.g. HTTP headers) is 259 exposed to the layer-7 router or proxy. In this type of RRS, a 260 surrogate can be chosen based on, for example, a full URL. Another 261 example of in-line request-routing is when an origin server (or 262 reverse proxy) performs a layer-7 redirection by "URL-rewriting". 264 There are three major differences between an "in-line" request- 265 routing system and a DNS-based request-routing system. The first is 266 that the full content request is exposed (e.g. a full URL). The 267 second is that the content type of the request is exposed (again from 268 the full URL). The third is that all client requests can be received 269 by the request-routing system; this is in contrast to DNS-based 270 systems where caching may prevent this. 272 2.1.2.1 "In-Line" Example 274 Assume client X is configured to forward its requests to layer-7 275 request-router R. Furthermore assume that request-router R is a CIG 276 for content network CN-A. When a request from client X is received, 277 request-router R makes a request-routing decision based on its 278 content topology database constructed from information communicated 279 from other neighbor CNs. If request-router R can service the request 280 within its own distribution system then the request is sent to a 281 surrogate that is part of CN-A. If request router R decides to 282 direct the client to another neighbor CN, a redirect is sent to the 283 client to direct the cilent to another layer-7 request-router in a 284 neighboring CN. In summary, when "in-line" request routing is used, 285 the redirection decision is based on the following: 287 1. Information contained in area advertisements that have been 288 received from neighbor CNs. An example may be an IP prefix 289 advertised with an associated metric. 291 2. The ability of neighbor CNs to support the content type of the 292 request. An example may be a set of content types supported. 294 3. Information contained in content advertisements from neighbor 295 CNs that may include: content metrics, availability of content, 296 etc. For "in-line" request-routing systems this may include full 297 URLs or URL sets. 299 4. Local request-routing policy. 301 2.2 Request-Routing Interconnection Model 303 Request-routing systems (RRS) present a "black-box" view of their 304 associated distribution systems. Since in such an environment no CN 305 possesses a global view of all other CNs, the request-routing system 306 must also rely on a peer-to-peer model in which each request-routing 307 system is only aware of its direct neighbor. [Note: A direct 308 neighbor of the request-routing systems does not have to be a direct 309 neighbor at Layer-3]. 311 There are two methods for redirecting a request between two 312 interconnected request-routing systems. The first method is an 313 iterative method where a RRS directs the request to the next-best 314 (neighbor) RRS. This continues until a surrogate is finally 315 selected. The second method is recursive where a RRS directs a 316 request to the next-best RRS but expects an answer to return to the 317 client. These two methods are analogous to recursive vs. iterative 318 DNS lookups. 320 An example of how requests can be directed between CNs is through the 321 use of DNS CNAMEs. When DNS-based request-routing systems are 322 interconnected and redirecting requests using CNAMEs, a clients DNS 323 resolution is redirected using a DNS CNAME record to another DNS- 324 based request-routing system until a surrogate is found that is 325 appropriate (according to a set of metrics) to serve the content. 326 The drawbacks of CNAME based request-routing are discussed in [KNOWN 327 MECH]. 329 2.3 CN Capabilities 331 Request-routing systems are associated with one or more distribution 332 systems. When a request-routing system directs a client request it 333 must ensure that: 335 1. The client request type can be serviced by the distribution 336 system (e.g. HTTP vs. RTSP). 338 2. The distribution system to which a client is directed has the 339 capacity to service the request. 341 In order to ensure that an interconnected (neighbor) CN can service a 342 request, a request-routing system is required to have the following 343 information about neighbor CNs: 345 1. Request-routing system types. 347 2. Content types that can be served by the CN. 349 3. Sets of metrics that are used for direction. 351 This information maybe obtained manually (off-line) or through the 352 use of dynamic (on-line) information exchange protocols. 354 2.4 Request-Routing Information Exchange 356 Interconnected request-routing systems need to exchange information 357 in order to make request-routing decisions. The two request-routing 358 system types presented in section 1.2 have slightly different 359 requirements with respect to the types of information exchanged. In 360 summary, interconnected request-routing systems need to exchange two 361 basic types of information: 363 1. Area Advertisements: Advertisements from a CN's request-routing 364 system about aspects of topology, geography and performance of a 365 CN. 367 2. Content Advertisements: Advertisements from a CN's request- 368 routing system about the availability of one or more collections of 369 content on CN. This may include for example: urls, content types, 370 distribution model, authoritative request-routing system, etc. 372 Request-routing information exchange follows the model of layer-3 373 routing protocols. That is, advertisements are sent to neighbor CNs 374 and each request-routing system makes its own decisions. The design 375 of an information exchange protocol must take the following into 376 consideration: 378 - Information exchange may occur over highly unreliable networks. 380 - Information exchange protocols may be required to exchange large 381 sets of advertisement information. 383 - Information exchange may occur over insecure networks. 385 - Arbitrary meshed topologies may exist for information exchange 386 protocols. 388 2.5 Request-Routing Decision 390 Request-routing systems make decisions based on one or more 391 advertisement types and their associated metrics. Both content 392 advertisements and area advertisements may be used to construct a 393 request-routing content topology database. This table is used to 394 determine how requests should be directed. The request-routing 395 decision process is complex for the following reasons: 397 - Content delivery networks are overlay networks which inherently 398 makes decision processes more complex. 400 - There are many possible metrics; if multiple metrics are 401 exchanged, loop prevention may be difficult. 403 - Request-routing systems may have specific policies with respect 404 to direction. 406 - Request-routing decisions are independent; therefore request- 407 routing loops must be prevented. 409 2.6 Request-Routing Protocol Design 410 In order to interconnect request-routing systems, one or more 411 protocols are required to exchange request-routing information. 412 These protocols are designed to operate in an inter-domain context 413 and therefore have the following considerations: 415 - Protocol sessions will need to be debugged across CN boundaries. 417 - Large sets of information may be exchanged between CNs. 419 - Policy based request-routing is needed in many scenarios. 421 - Protocol designs should be "Internet" scalable. 423 3. Request-Routing System and Protocol Requirements 425 3.1 General Requirements 427 In the following section we describe the general requirements for 428 protocols to be used in the interconnection of request-routing 429 systems. 431 - Request-routing protocols MUST use an administrative identity to 432 identify themselves in protocol exchanges. 434 - Request-routing protocols SHOULD support arbitrary direction 435 topologies; this means "peer-to-peer" design. 437 - Request-routing protocols MUST treat other content networks as 438 "black boxes"; that is, a given CN A does not normally posses 439 direct visibility into another neighbor CN B. 441 - Request-routing protocols MUST support methods to determine the 442 authoritative request-routing system for content. 444 - Request-routing protocols SHOULD be compatible with existing 445 applications and protocols. 447 3.2 Request-Routing System Type Requirements 449 The following section describes the information exchange protocol 450 requirements that apply to both DNS-based and in-line request-routing 451 systems. 453 - Request-routing protocols SHOULD support DNS-based and in-line 454 request-routing system types. 456 - Request-routing protocols MUST be extensible to support other 457 request routing system types. 459 - Request-routing protocols MUST communicate their request-routing 460 system type to neighbors (e.g. DNS-based). 462 - Request-routing protocols MAY allow for utilization of more than 463 one request-routing system type for content. 465 - Request-routing protocols MUST be able to identify content types 466 for content. 468 3.2.1 DNS-Based Request-Routing Requirements 470 The following section describes the information exchange protocol 471 requirements that apply to DNS-based request-routing system types. 473 - Request-routing protocols MUST support CNAME based DNS 474 redirection. 476 - Request-routing protocols MUST be able to map content types to 477 CNAMEs in order to make proper direction decisions. 479 3.2.2 In-Line Based Request-Routing Requirements 481 The following section describes the information exchange protocol 482 requirements that apply to in-line based request-routing system 483 types. 485 - Request-routing protocols MUST support application layer 486 redirection (e.g. HTTP redirection). 488 - Request-routing protocols SHOULD support explicitly configured 489 application gateways and proxies. 491 3.3 Request-Routing Interconnection Model Requirements 493 The following section describes the information exchange protocol 494 requirements for the model of CN interconnection. 496 - Request-routing protocols MUST allow for delegation of requests 497 to another request-routing system. 499 - Request-routing protocols SHOULD support both iterative and 500 recursive redirection models. 502 - Request-routing protocols SHOULD require that content have only 503 one authoritative request-routing system. 505 - Request-routing protocols MUST verify that neighbor CNs have the 506 ability to deliver content before directing requests to that 507 neighbor. 509 3.4 Request-Routing System Capabilities Requirements 510 The following section describes the information exchange protocol 511 requirements for request-routing system capability information. 513 - Request-routing protocols MUST support the advertisement of 514 content type information between neighbors. 516 - Request-routing protocols SHOULD have primitive methods for 517 capability advertisement. 519 3.5 Request-Routing Information Exchange Requirements 521 3.5.1 General Information Exchange Requirements 523 The following section describes the information exchange protocol 524 requirements with respect to general types of information exchanged. 526 - Request-routing protocols MUST define standardized methods for 527 identifying an atomic unit of content. 529 - Request-routing protocols MUST define standardized methods for 530 identifying distribution system capabilities (e.g. content types, 531 layer-3 coverage, etc). 533 - Request-routing protocol MUST not preclude request-routing 534 systems from implementing policy based routing decisions. 536 - Request-routing protocols MUST support the exchange of multiple 537 basic information types (e.g. area and content advertisements). 539 - Request-routing protocols MUST be able to associate multiple (and 540 optional) metrics with each basic information types. 542 - Request-routing protocols MUST exchange information sufficient to 543 avoid looping of information advertisements. 545 - Request-routing protocols MAY exchange information sufficient to 546 prevent request-routing loops. 548 3.5.2 Specific Information Exchange Requirements 550 The following section describes the information exchange protocol 551 requirements with respect to specific types of information exchanged. 553 - Request-routing protocols MUST support the exchange of area 554 advertisements (e.g. IP prefixes) between request-routing systems. 556 - Request-routing protocol area advertisements MUST support the 557 inclusion of multiple capabilities and metrics (e.g. X Mbps, Y CIDR 558 blocks, Z static http). 560 - Request-routing protocols SHOULD define a minimum set of metrics 561 for area advertisements. 563 - Request-routing protocols MUST support the exchange of content 564 advertisements (e.g. URIs) between request-routing systems. 566 - Request-routing protocol content advertisements MUST support the 567 inclusion of multiple metrics. 569 - Request-routing protocol content advertisements MUST support the 570 ability to advertise the availability of content. 572 - Request-routing protocol content advertisements SHOULD identify 573 the authoritative request-routing system. 575 - Request-routing protocols SHOULD define a minimum set of metrics 576 for content advertisements. 578 - Request-routing protocols MUST accommodate hierarchy and 579 aggregation in content and area advertisements. 581 3.6 Request-Routing Decision and Policy Requirements 583 The following section describes the information exchange protocol 584 requirements with respect to request-routing decision making. 586 - Request-routing protocols MUST be "policy friendly" (e.g. support 587 additional neighbor-to-neighbor extensible attributes). 589 - Request-routing protocols SHOULD support exchange of information 590 sufficient to prevent routing loops. 592 - Request-routing protocols MAY support multiple metrics for 593 direction decisions as long as routing decisions can be guaranteed 594 loop free. 596 3.7 Request-Routing Information Exchange Protocol Attribute Requirements 598 The following section describes the information exchange protocol 599 requirements with respect to the specific attributes of the protocol 600 design itself. Note that some of these requirements are redundant 601 with other sections; we repeat them here for organization. 603 - Request-routing protocols MUST use a reliable transport protocol. 605 - Request-routing protocols MUST make use of existing IETF 606 developed security mechanisms for encryption and authentication. 608 - Request-routing protocols MUST include protocol notifications for 609 protocol error conditions. 611 - Request-routing protocols SHOULD be connection oriented. 613 - Request-routing protocols MUST provide mechanisms to prevent 614 looping of advertisement information. 616 - Request-routing protocols MUST have extensible packet formats. 618 - Request-routing protocols MUST properly identify neighbors. 620 - Request-routing protocols MUST properly authenticate neighbors. 622 - Request-routing protocols MUST scale to accommodate the exchange 623 of large sets of content and area advertisements. 625 - Request-routing protocols MUST support (at a minimum) a simple 626 capability exchange/advertisement. 628 - Request-routing protocols MUST NOT exchange policy information. 630 - Request-routing protocols MUST accommodate policy based request- 631 routing systems. 633 4. Security Considerations 635 Since request routing systems are responsible for routing client 636 requests to surrogates protecting request routing systems from 637 attackers is crucial. If any request routing system is compromised 638 an attacker could deny service to all or some clients and/or alter 639 the content distributed by the "master" or "authoritative" origin 640 server for all or some clients. Protecting the request routing system 641 requires multiple components: 643 1. Request routing systems have to ensure that their peers are 644 properly authenticated and the integrity of the communication between 645 the peers is ensured. This could be achieved by the use of IPSEC or 646 TLS. Any protocols designed for communication between request routing 647 systems MUST address this issue. 649 2. Each request routing system has to decide if its peer is 650 authorized to advertise a particular piece of content for a 651 particular region. To address this issue every request routing 652 system MUST allow the operator to specify a policy which reflects the 653 legal framework governing the authorization of advertisement. 655 3. To contain the damage a broken instance of a request routing 656 system can make each request routing system MUST apply the policy 657 specified in 2. on any advertisement received before re-advertising 658 the advertisement. 660 5. References 662 [MODEL] Day, M., Cain, B., Tomlinson, G., P. Rzewski "A Model for 663 Content Internetworking (CDI)", draft-ietf-cdi-model-02.txt (work in 664 progress), May 2002. 666 [KNOWN MECH] Barbir, A., Cain, B., Douglis, F., Green, M., Hofmann, 667 M., Nair, R., Potter, D. and O. Spatscheck, "Known CDN Request- 668 Routing Mechanisms", draft-ietf-cdi-known-request-routing-01.txt 669 (work in progress), May 2002. 671 [ARCH] Green, M., Cain, B., Tomlinson, G., Thomas, S. and P. Rzewski, 672 "Content Internetworking Architectural Overview", draft-ietf-cdi- 673 architecture-00.txt (work in progress), February 2002. 675 6. Author's Address: 677 Brad Cain 678 Storigen Systems 679 bcain@storigen.com 681 Oliver Spatscheck 682 AT&T Labs 683 spatsch@research.att.com 685 Martin May 686 Activia Networks 687 Martin.May@activia.net 689 Abbie Barbir 690 Nortel Networks 691 abbieb@nortelnetworks.com 693 7. Acknowledgements 695 Thanks to the following people for their contributions: John Martin, 696 Nalin Mistry, Mark Day, Stephen Thomas, Hillary Orman, Phil Rzewski, 697 and Fred Douglis. 699 The IETF has been notified of intellectual property rights claimed in 700 regard to some or all of the specification contained in this 701 document. For more information consult the online list of claimed 702 rights. 704 Full Copyright Statement 706 Copyright (C) The Internet Society (2000). All Rights Reserved. 708 This document and translations of it may be copied and furnished to 709 others, and derivative works that comment on or otherwise explain it 710 or assist in its implementation may be prepared, copied, published 711 and distributed, in whole or in part, without restriction of any 712 kind, provided that the above copyright notice and this paragraph are 713 included on all such copies and derivative works. However, this 714 document itself may not be modified in any way, such as by removing 715 the copyright notice or references to the Internet Society or other 716 Internet organizations, except as needed for the purpose of 717 developing Internet standards in which case the procedures for 718 copyrights defined in the Internet Standards process must be 719 followed, or as required to translate it into languages other than 720 English. 722 The limited permissions granted above are perpetual and will not be 723 revoked by the Internet Society or its successors or assigns. 725 This document and the information contained herein is provided on an 726 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 727 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 728 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 729 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 730 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 732 Acknowledgement 734 Funding for the RFC editor function is currently provided by the 735 Internet Society.