Network Working Group February 2002 Internet-Draft Brad Cain Expires: August 25, 2002 Cereva Networks Oliver Spatscheck AT&T Lisa Amini IBM Research Abbie Barbir Nortel Networks Martin May Delphine Kaplan Activia Content Network Advertisement Protocol (CNAP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2002. Copyright Notice Copyright (C) The Internet Society ( 2002). All Rights Reserved. Abstract The Content Network Advertisement Protocol (CNAP) is a protocol Intended to facilitate the interconnection of Content Networks (CN). CNAP is a simple CN-to-CN information exchange protocol that advertises both content and area advertisements. These two types of advertisements are described in [3,6] and are intended to be used by content network request routing systems [9]. The exchange of these advertisements between CNs is intended to facilitate inter-CN request-routing decisions. Cain, et. al. Expires August 25, 2002 page [1] Internet-Draft CNAP August 2002 1. Introduction The document provides the specifications of the Content Network Advertisement Protocol (CNAP), which is designed to facilitate the interconnection of separately administered Content Networks [9]. In this work, the term, Content Network (CN), refers to a collection of network elements that assist in the distribution, location, delivery and usage-tracking of content [9]. In [9] a CN is generally composed of a set of surrogates and three principal architectural components: a Distribution System, a Request-Routing System and an Accounting System. The CNs interconnects through a Content Internetworking Gateway (CIG) that supports the three architectural components. The source CN for a given content is the Authoritative CN for that content. A content provider can be the Authoritative CN provided that it supports at least a request-routing system [9]. This document defines a simple advertisement protocol that is intended to communicate information for the purpose of performing request routing [3] decisions between interconnected CNs. CNAP is not a routing protocol but can be used to exchange information that may be used for inter-CN request-routing decisions. This document includes the following: - An overview the necessary protocols needed to interconnect content networks and where CNAP fits in this model. - An overview of how CNAP can interface to the other (as not yet defined)content networking protocols such as a content distribution protocol [8]. - An overview of the context for CNAP. - The specification of CNAP and its operation. CNAP primary role is to exchange request-routing information Between CNs; this information may be used to facilitate inter-CN request-routing decisions. CNAP is used to advertise: - Advertisement of Content served by a CN using content advertisements. Content advertisements may include a number of attributes concerning the content. - Advertisement of CN information about aspects of topology, geography and performance using area advertisements. Area advertisements may include a number of attributes/metrics relating to a CN's topology. Cain, et. al. Expires August 25, 2002 page [2] Internet-Draft CNAP August 2002 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2. CNAP Architectural and Operational Overview This section outlines the context for CNAP and the various steps and protocols that are needed to perform basic interconnection between content networks. Furthermore, the section provides the basis for understanding the specific problems that the CNAP protocol is addressing. In section 3 the specification for CNAP is provided. 2.1 Overview The interconnection of CNs must be performed in multiple steps and requires the exchange of multiple types of information. In particular, there are three steps of CN interconnection: 1. The first step in interconnecting CNs starts when one CN requests the distribution of particular content on a neighboring CN. This task can be performed manually or through a set of automated protocol(s). This step must provide various attributes of the content to be distributed such as its origin and invalidation scheme. The requesting CN is the authoritative CN for that content. This step is also called Request for Distribution. 2. After performing step 1, the two CNs must exchange information about the content that they have agreed to distribute. In particular, the two CNs must exchange readiness and metric information about the content between them. Other information that is necessary to perform request-routing decisions (i.e. request redirection) must also be advertised. The information might include metrics such as Latency, Packet Loss, and Hop Counts. In [12], a detailed list of metric information that can be used in performing request-routing decisions is provided. The advertisement of such information is the purpose of the Content and Network Advertisement Protocol (CNAP). The details of CNAP are described in this document. Cain, et. al. Expires August 25, 2002 page [3] Internet-Draft CNAP August 2002 3. The third step consists of the task of ensuring that the content is up to date between the two interconnected CNs. In this regard, it is necessary for the authoritative CN to ensure that content on the neighboring CN is updated in a proper manner. This task may require a cache invalidation or meta-data protocol exchange. The next sections provide more detailed description of the steps that are needed to interconnect CNs as part of the CNAP protocol. The document focus on the CNAP protocol and does not detail the steps that are needed to perform a routing decision. 2.2 Request for Distribution Step We refer to the first step in above process as the distribution request phase. This can be handled manually or through an automated protocol(s). In this phase, a CIG requests the distribution of content from a neighboring CIG (associated with another CN). This step can be automated by the use of a content distribution request protocol. This protocol is responsible for providing: - A request/response mechanism to ask a neighbor CN to advertise content. - The required information for retrieving the content (e.g. origin). - The required information for properly accounting for the content. - The invalidation channel to receive invalidations and meta- data updates for the content. 2.3 Information Exchange and Inter-CN Request-Routing Step Once a CN has agreed to distribute content for another CN, then each CN must exchange two types of information in order to determine whether a request (or set of requests) will be handed to a neighbor CN. Each CN exchanges two types of information with the neighboring CNs. The two types of information are area advertisements and content advertisements. These advertisements allow a CN to determine the availability of content as well as the health/performance of a neighbor CN. This information is used to make inter-CN request-routing decisions. The CNAP is a simple advertisement protocol that will be used for exchanging information between CNs. Cain, et. al. Expires August 25, 2002 page [4] Internet-Draft CNAP August 2002 2.3.1 CIG Abstract Model Neighboring CNs are interconnected through CIGs. The CNAP protocol runs on CIGs. A CIGs contains several basic components that are depicted in Figure 1. Next a brief description of the components is provided. CIG ___________________________ | ___________________ | | | Content Topology | | | | Database | | | | (CTD) | | | |--------------------| | | ____________________ | | | Local Content | | | | Routing Matrix | | | | (LCRM) | | | |--------------------| | | ____________________ | | | Route | | | |Computation Process | | | | (RCP) | | | |--------------------| | | ____________________ | | |Content Forwarding | | | |Information Base | | | | (CFIB) | | | |--------------------| | |---------------------------| Figure 1. Content Routing Components 1. Content Topology Database (CTD) The Content Topology Database consists [6] of three distinct components: a) Content routing information that has been learned from inbound CNAP advertisement messages. They carry routes that are available as an input to the Route Computation Process. b) Content routing information on which the CN is Authoritative on and that has been selected by applying local policies to the routing Information in step a) and stored in the Content Routing Matrix. c) The information that CNAP advertises to other interconnected CNs. Cain, et. al. Expires August 25, 2002 page [5] Internet-Draft CNAP August 2002 Each CNs has to keep track of the list of content for which it is authoritative. 2. Route Computation Process (RCP) The Route Computation process is responsible for: - Keeping track of newly learned AREAs and CONTENTs that can be reached by other CNs, - Keeping track of newly distributed CONTENTs/AREAs of the CN that have to be advertised to content level peers, and - Updating the Content FIB accordingly. 3. Local Content Routing Matrix (LCRM) This matrix is local to each CN. It contains information about content learned from the Distribution System and is used to route requests to local surrogates that will actually serve the content. 4. Content Forwarding Information Base (CFIB) This database is constructed using the content information that is available in CTD and LCRM. The information in this database indicates to the RRS system of the CN when requests to a given content must be forwarded to other peered CNs or served locally. 2.4 Content Meta-Data Updates Step Once content has agreed to be distributed and is being advertised by a neighboring CN, there must exist a way to update meta-data related to that content. An example of this step is the information that is required to invalidate content. The primary differences between the type of information advertised in CNAP and the types advertised in meta-data updates are: - CNAP advertises *CN* aggregate information to its neighbors. A meta-data update protocol would advertise *content* specific updates. In other words, CNAP updates are always with respect to the network itself. Cain, et. al. Expires August 25, 2002 page [6] Internet-Draft CNAP August 2002 - CNAP content advertisements are expected to be long- lived. A meta-data update protocol would advertise potentially short-lived information (e.g. content expiration times). A meta-data update protocol would advertise frequent updates where CNAP is intended for only network-wide infrequent updates (e.g. now distributing new content set). 3. Content Advertisement Protocol (CNAP) 3.1 Introduction This section provides an overview, operation, and detailed protocol specification for the Content Network Advertisement Protocol (CNAP). The primary function of CNAP is to exchange content and reachability information as it relates to Content Networks. Reachability applies to both network reachability and content reachability. CNAP is a CN to CN protocol and makes use of TCP as a reliable transport protocol. TCP is used due to the large amounts of information that must be exchanged using CNAP. Furthermore, the number of CNAP connections is small since CNAP is used for connecting overlay networks. Information exchanged between CNs using CNAP is communicated on a neighbor-by-neighbor basis. That is, a CIG may filter information based on policies configured by the CIG administrator. 3.2 Information Types CNAP advertises information for the following purposes: - The readiness (or not) of a CN to serve content - How the authoritative CN should redirect requests to the CN. - Information that may be used for inter-CN request-routing decisions. The above information is advertised in two types of advertisements: - Content Advertisements: Advertisement from a content network's request-routing system about the availability of one or more collections of content on a content network. These advertisements are keyed on URLs that specify content. They specify the readiness to serve sets of content as well as other information required for inter-CN request routing. Cain, et. al. Expires August 25, 2002 page [7] Internet-Draft CNAP August 2002 - Area Advertisements: Advertisement from a content network's request-routing system about aspects of topology, geography and performance of a CN. These advertisements specify information related to making an informed inter-CN request routing decision. These are keyed on IP prefix/length pairs and contain metrics from a CN to those prefixes. NOTE: Need to add IP v6 info. 3.3 CNAP Protocol Overview CNAP is a simple point-to-point (CIG to CIG) advertisement protocol to be used for exchanging CN information. CNAP does not specify actual inter-CN request-routing algorithms but is intended to be used as an information exchange protocol for the purpose of inter-CN request routing. CNAP is a text-based protocol using TCP as its underlying transport mechanism using port number TBD. A single CNAP connection exists between a set of CIGs. CNAP makes use of the concept of a Content Network Autonomous System (CNAS). A CNAS is an identifier assigned through an address authority on a per content network basis. It is similar to the Autonomous System (AS) identifier used in inter-domain IP routing. Initially, CNAP is specified for DNS-based request-routing systems. For this reason, this document specifies the Redirection Parameter Set for DNS-based request routing. However, CNAP is extensible for other request-routing types. The high-level protocol design of CNAP and connection state machine borrows from BGP-4 [13]. It includes four types of messages: OPEN, KEEPALIVE, NOTIFY, ADVERTISE. CNAP includes the notion of a "Content Autonomous System" (Content AS). A Content Autonomous System is a single administrative CN. The Content Autonomous System is included in a number of CNAP protocol messages. CNAP is designed to be extensible to support new attributes, metrics, and advertisement types. 3.4 CNAP Connections CNAP connections must be explicitly configured by an administrator (this is similar to BGP). Before a CNAP session can be established the operators of the CIGs involved in a CNAP session have to establish: Cain, et. al. Expires August 25, 2002 page [8] Internet-Draft CNAP August 2002 - Local CNAS - Local CIG IP address - Neighbor CNAS - Neighbor CIG IP address - Security credentials - And any advertisement filtering policies After this information has been configured either site MAY initiate a CNAP session by establishing a TCP connection and exchanging CNAP messages as described in the next section. A CNAP connection is fully established only when the connection enters the READY state. After the CNAP connection enters the READY state, it may begin exchanging network and/or content reachability information. In order to prevent redundant TCP connections between CIGs, the CIG with the lowest IP address wins in a tie-breaking situation. If a CIG detects multiple connections to a neighbor the one with the lowest IP address "wins" the election; that is, the connection initiated from the CIG with the lowest IP address is kept. The other is torn down. 3.5 CNAP Messages and Formats CNAP is text-based, using ISO 10646 in UTF-8 encoding (RFC 2279 [13]). This allows easy of debugging and makes CNAP flexible and extensible. The following are used within CNAP messages: NOTE: Need to add IP v6 info. CNAP-URI = URI-PARAMETERS PROTOCOL-VERSION = 1*3DIGIT ; 0 TO 255 CNAS = 1*16DIGIT ; HOLDTIME = 1*3 DIGIT ; 0 TO 255 DISTRIB-LEVEL-TYPES = ("MULTIPLE" | "SINGLE") RRS-TYPE = ("DNS-CNAME") IP-VERSION = ("4" | "6") IPV4-ADDRESS = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT IPV4-MASK = 1*DIGIT IPV6-PARAMETER = TBD OTHER-PARAM = (token | (token "=" (token | QUOTED- STRING))) ADVERT-TYPE = ("AREA" | "CONTENT") CONTENT-AS-PATH = *((1*5DIGIT) [","]) AREA-LIST = *((IPV4-ADDRESS "&" IPV4-MASK)[","]) ERROR-DATA = *(ALPHANUM) STATUS-TYPE = ("ADD" | "WITHDRAW") REGION-ID-LIST = *((1*16DIGIT) [","]) REGION-ID = *((1*32DIGIT) [","]) RDIR-VALUE = *(ALPHANUM) Cain, et. al. Expires August 25, 2002 page [9] Internet-Draft CNAP August 2002 In general, CNAP messages consist of a start-line, a header field (also known as "message-header"), and an empty line indicating the end of the header field. generic-message = start-line [message-header] CRLF The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present. 3.5.1 Message Header Fields Each CNAP message contains a small one-line header that includes the message type. Each message type has its own unique header. There are three types of header fields, mainly: "open-header", "notification-header", "advertisement-header". The syntax of the message header is given below: message-header = ( open-header | notification-header | advertisement-header ) The message-header fields follow the same generic header format as that given in section 3.1 of RFC 822 [X]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of leading white space (LWS), though a single space (SP) is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). CIGs MUST follow HTTP "common form" when generating these constructs. Message-header = field-name ":" [field-value] CRLF Field-name = token Field-value = *(field-content |LWS) Field-content = Cain, et. al. Expires August 25, 2002 page [10] Internet-Draft CNAP August 2002 3.5.2 Message Types Each CNAP message contains a small one-line header defined by: start-line = Method CRLF Each method corresponds to a CNAP message type. The Method token is case-sensitive. Method = "OPEN" | "NOTIFY" | "ADVERTISEMENT" | "KEEPALIVE" The following sections describe CNAP messages and the content of these messages. 3.5.2.1 OPEN The OPEN message is sent by each CIG in a CNAP session to initiate and establish the CNAP protocol connection. Each CIG sends an OPEN message as soon as the TCP connection is established. An OPEN message contains an open-header: open-header = PROTOCOL-VERSION | NODE-ID | CNAS | HOLDTIME | DISTRIB-LEVEL | RRS-TYPES where, - Protocol-Version CNAP protocol version number running on the CIG gateway. PROTOCOL-VERSION = "Protocol-Version" ":" Protocol-Version - NODE-ID The Node ID is an unique IP address of the CIG. NODE-ID = " NODE-ID" ":" IPV4-ADDRESS, or NODE-ID = " NODE-ID" ":" IPV6-ADDRESS - CNAS The Content Network Autonomous System that uniquely identifies this content network. Each CN is assigned a CNAS by an addressing authority. Content-AS = "Content-AS" ":" CNAS Cain, et. al. Expires August 25, 2002 page [11] Internet-Draft CNAP August 2002 - HOLDTIME Keepalives expected in this interval. HOLDTIME = "HOLDTIME" ":" HOLDTIME - DISTRIB-LEVEL Number of levels supported for request routing for this CN. DISTRIB-LEVEL = " DISTRIB-LEVEL" ":" DISTRIB-LEVEL-TYPE - RRS-Types list of RRS types supported by this CN. RRS-TYPES = "RRS-TYPES" ":" *(RRS-TYPE) - CNAP-ABILITIES List of optional CNAP-ABILITIES supported by the CN. CNAP-ABILITIES = *( CNAP-ABILITY) 3.5.2.2 KEEPALIVE KEEPALIVE messages are sent according to the period specified for HOLDTIME in the OPEN message. No parameters are supported for KEEPALIVE messages. KEEPALIVE messages are used to acknowledge OPEN messages. After a CIG receives a KEEPALIVE in response to its OPEN, it enters the ESTABLISHED state assuming that its neighbor is ready to begin receiving advertisements. A KEEPALIVE message contains no specific method header. 3.5.2.3 NOTIFY NOTIFY messages are sent to indicate an error has occurred. The sender will move to the Idle state immediately after sending the NOTIFY message. notify-header = ERROR-CODE | ERROR-SUBCODE | ERROR-DATA where, - ERROR-CODE Error code indicates the type of notification. Error-Code = "Error-Code" ":" 3DIGIT Cain, et. al. Expires August 25, 2002 page [12] Internet-Draft CNAP August 2002 - ERROR-SUBCODE Sub-code within a given error code type. If no specific error subcode applies, the subcode should be set to zero. Error-Subcode = "Error-Subcode" ":" 3DIGIT - Error-Data Additional information regarding the error. Error-Data = "Error-Data" ":" *(alphanum) Currently defined error-codes are listed below: 1 - OPEN Message Error 2 - CONTENT Message Error 3 - AREA Message Error 101 - Invalid Message 102 - Hold Timer Expired 103 - Session Security Required 104 - Finite State Machine Violation 105 - Session Shutdown The following are currently defined error sub-codes: OPEN Error Subcodes 1 - Protocol Version not supported 2 - Different distribution levels 3 - Mandatory CNAPability not provided 4 - RRS not supported 5 - different metrics for same content type CONTENT Error Subcodes AREA Error Subcodes Editor Note: Need to expand Error Subcodes 3.5.2.4 ADVERTISE ADVERTISE messages contains the actual content and CN information. They are used to advertise positive status as well as to withdraw information. Content and Area ADVERTISE messages are "linked" through Region IDs (RID). A RID is a 32-bit unsigned integer assigned to one or more IP prefixes. If a Content ADVERTISE message contains RID, it means "this content is available in these areas with these RIDs". Cain, et. al. Expires August 25, 2002 page [13] Internet-Draft CNAP August 2002 Editor Note: Need to define RegionIDs. Editor Note: Need to properly define TTL. advertisement-header = ADVERTISEMENT-TYPE | AUTHORITATIVE-CN | CN-PATH | (AREA-HEADER | CONTENT-HEADER) - ADVERTISEMENT-TYPE This specifies the type of advertisement. ADVERTISEMENT-TYPE = "ADVERTISEMENT-TYPE" ":" ADVERT-TYPE - AUTHORITATIVE-CN The CAS number of the CN authoritative for the CONTENT or AREA being advertised in this message. AUTHORITATIVE-CN = "AUTHORITATIVE-CN" ":" CONTENTAS - CN-PATH Attribute that is composed of a sequence of CAS numbers. CN-PATH = "CN-PATH" ":" CONTENT-AS-PATH The following sections describe the details of each of the advertisement types above. An "area" advertisement includes an area-header that is a list of areas (and their metrics) being advertised. A "content" advertisement includes a content-header that is a list of content (and its metrics) being advertised. 3.5.2.4.1 ADVERTISE: Content Content advertisements are used to advertise information relating to content. This information advertises the status and related request routing information related to content. content-header = CONTENT-SET | STATUS | REGION-LIST | TTL | REDIRECTION-INFO - Content-Set The content set specifies a set of URL's or URL prefixes. The granularity of the content-set might depend on the redirection-type if defined. CONTENT-SET = "CONTENT-SET" ":" *( (CNAP-URI) [","] ) Cain, et. al. Expires August 25, 2002 page [14] Internet-Draft CNAP August 2002 - Status The status of the content set for the advertising CN. The status-type may be either "ready" or "withdraw". Ready indicates the CN can accept request for content within the content-set. Withdraw indicates that requests for content within the content-set should not be sent to the advertising CN. Status = "Status" ":" status-type - Region-List List of 16-bit region IDs for which the content is available. Region-List = "Region-List" ":" region-id-list - TTL Indicates for how long the CN will be ready for content in the content set in minutes. TTL = "TTL" ":" 32DIGITS If a content advertisement indicates a Status of "ready", then REDIRECTION-INFO is also supplied in the advertisement. REDIRECTION-INFO = REDIRECTION-TYPE | REDIRECTION-VALUE where, - Redirection-Type Type of redirection parameter set used. REDIRECTION-TYPE = "REDIRECTION-TYPE" ":" RRS-TYPE - Redirection-Value Value of redirection parameter set (terminated by CRLF like other headers). See Section 4 for the structure of the Redirection value for cname based request routing systems. REDIRECTION-VALUE = "REDIRECTION-VALUE" ":" RDIR-VALUE If a content advertisement indicates a Status of "withdraw", then REDIRECTION-INFO is also supplied in the advertisement. REDIRECTION-INFO = WITHDRAW-EFFECTIVE where, Cain, et. al. Expires August 25, 2002 page [15] Internet-Draft CNAP August 2002 - WITHDRAW-EFFECTIVE When the withdraw will be effective (might be 0). A withdraw MAY withdraw content before the TTL in a previous ready message is reached. If the TTL in the ready message is reached the content is considered withdrawn. WITHDRAW-EFFECTIVE = "WITHDRAW-EFFECTIVE" ":" 32DIGITS 3.5.2.4.2 ADVERTISE: Area Area advertisements communicate metrics for areas that are accessible via the advertising CN. area-header = AREA-SET | STATUS | REGION-LIST | TTL | METRIC-LIST Area-Set: List of IP prefixes pairs for which the advertisement holds. AREA-SET = "AREA-SET" ":" AREA-LIST - Status The status of the area set for the advertising CN. The status-type may be either "ready" or "withdraw". Ready indicates the CN can accept request for the IP prefixes within the area-set. Withdraw indicates that requests for content within the area-set should not be sent to the advertising CN. STATUS = "STATUS" ":" STATUS-TYPE - Region-List List of 32-bit region IDs for which the that are identified with the area set. REGION-LIST = "REGION-LIST" ":" REGION-ID-LIST - TTL Indicates for how long the CN the area advertisement is valid in minutes. TTL = "TTL" ":" 32DIGITS Cain, et. al. Expires August 25, 2002 page [16] Internet-Draft CNAP August 2002 If an Area ADVERTISE message indicates a Status of "ready", then metric-list is also part of the area-header. METRIC-LIST = *(METRIC) METRIC = METRIC-TYPE| METRIC-VALUE where, - Metric-Type Type of metric reported. METRIC-TYPE = "METRIC-TYPE" ":" 16DIGIT - Metric-Value Value of metric; depends on type. METRIC-VALUE = "METRIC-VALUE" ":" *(ALPHANUM) 3.6 Error Handling 3.6.1 Session Initiation Collision If an OPEN is received for a CN for which the CIG has another session established the CN with the higher CN number will send a NOTIFY message and move to the Idle state. 3.6.2 Protocol Version Negotiation Each CIG initially specifies the highest Protocol Version it is capable of handling. If the peer does not support this version, it sends a NOTIFY indicating the protocol version is not supported, and changes it's state to Idle. Either CIG may optionally re-establish the connection and specify a lower Protocol Version. Editor Note: we need to specify more error conditions. 3.7 Finite State Machine State is defined on a per peer basis, where a peer is Content Internetworking Gateway. 3.7.1 State Names The following states are defined. Init - No connection established. Cain, et. al. Expires August 25, 2002 page [17] Internet-Draft CNAP August 2002 OpenSent - An OPEN message has been sent. OpenConfirm - OPEN messages exchanged; confirmation required. Ready - Session is established. 3.7.2 State Table The following defines the state table. For each state, the messages, which are valid in that state, are listed. The "Next State After Success" column indicates the state entered after the message indicated in "Message Sent" is sent. If a message not specified for the state is received, the receiver will move to the Idle state, with the following exceptions: - A NOTIFY message is always followed by the sender moving to the Idle state. - AREA, CONTENT messages may only be sent in the Ready state and do not cause a state change. The OPEN sent in the Idle state MUST be sent by the initiator or The TCP connection between the CIG peers. The OPEN sent in the OpenSent state MUST be sent by the receiver of the initial OPEN message. State Message Sent Next State After Success -------- ------------ --------------------- Idle OPEN (initiator) OpenSent OpenSent OPEN OpenConfirm OpenConfirm KEEPALIVE Ready Ready KEEPALIVE Ready To move to the Idle state from any other state, the socket connection associated with this peer will be terminated. Data collected from AREA and CONTENT advertisements is retained only as long as the session is maintained. When a session moves to Idle state, the CIG will update it's AREA and CONTENT tables according to the following rules. For all AREA data received from a disconnected peer, AREA Status:Withdraw messages will be sent on remaining CNAP connections, and paths represented by the associated AREAs will be deleted from local tables. Cain, et. al. Expires August 25, 2002 page [18] Internet-Draft CNAP August 2002 4. Redirection parameter set: CNAME based DNS redirection The CNAME based DNS redirection parameter set is used if content is served by a CN, which uses CNAME, based DNS redirection. In this case the CN, which will serve the content, advertises in the READY message to the CN, which is authoritative for the DNS name of the content a CNAME. This CNAME MUST be used to redirect a DNS request from the authoritative CN to the CN advertising the CNAME if the authoritative CN wants to utilize the CN advertising the READY message. The parameter set is defined as: - Redirection-Type The redirection type should be specified as DNS CNAME. REDIRECTION-TYPE = "REDIRECTION-TYPE" ":" "DNS-CNAME" - Redirection-Value The CNAME to use for redirecting requests for content in the content set. REDIRECTION-VALUE = "REDIRECTION-VALUE" ":" *(ALPHANUM) If this redirection type is used the content set in a content advertisement MUST only be specified on the granularity of a DNS name. 5. Security Considerations The IPSEC architecture [11] defines security services at the IP level which can be used by any higher layer protocol. CNAP requires the ability to authenticate the session participants and to ensure the confidentiality of messages. These services are provided through use of IPSEC's Authentication Header (AH) and Encapsulating Security Payload (ESP), respectively. Because IPSEC targets providing services to security-unaware applications, CNAP requires only a mechanism to indicate to a peer that certain security services are required. Editor Note: expand details. Cain, et. al. Expires August 25, 2002 page [19] Internet-Draft CNAP August 2002 References [1] Bradner, S.O., "The Internet Standards Process – Revision 3", RFC 2026, BCP 9, October 1996. [2] Bradner, S.O., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 25, March 1997. [3] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CDN Peering Architectural Overview", January 2002. [4] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", January 2002. [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", January 2002. [6] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request Routing Requirements for Content Internetworking", January 2002. [7] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Accounting Requirements for CDN Internetworking", January 2002. [8] Amini, L., Spatscheck, O. and S. Thomas, "Distribution Requirements for Content Delivery Internetworking", January, 2002. [9] Day, M., Cain, B. and G. Tomlinson, "A Model for Content Distribution Internetworking", January 2002. [10] Day, M., Cain, B. and G. Tomlinson, "Content Distribution Network Peering Scenarios", January 2002. [11] Kent, S., Atkinson, R. and G. Tomlinson, "Security Architecture for the Internet Protocol", January 2002. [12] Cain et al, "Known CDN Request-Routing Mechanisms", draft-cain-cdnp-known-request-routing-04.txt (work in progress, November 2002). [13] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. Cain, et. al. Expires August 25, 2002 page [20] Internet-Draft CNAP August 2002 NOTES: [bec] took out global CN info in CNAPabilities; will use 0.0.0.0/0 to advertise metrics for entire CN (in area advertisement) [bec] message definitions are still a bit confusing; maybe we should simplify (and add stuff later)?? [bec] message definitions still need some work; need to reconcile with RFC2396 and RFC822 [bec] need to define all error types we can think of [bec] took out list of content types in open message; I think this is better suited for distribution protocol. If we put it back in then we should use standard mime types. [bec] left content AS path in all advertisements; even though we are just doing single level distribution now, I think it still makes sense as a mandatory requirement [bec] need more details in protocol state machine; see bgp RFC. [bec] took content type out of area advertisement; this makes things quite complex. Cain, et. al. Expires August 25, 2002 page [21] Internet-Draft CNAP August 2002 Author's Address Brad Cain Cereva Networks EMail: bcain@cereva.com Oliver Spatscheck AT&T Labs Room B131 180 Park Ave, Bldg 103 Florham Park, NJ 07932, US EMail: spatsch@research.att.com Lisa Amini IBM Research Email: aminil@us.ibm.com Abbie Barbir Nortel Networks 3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada EMail: abbieb@nortelnetworks.com Delphine Kaplan ActiVia Networks Space Antipolis 5 Parc de Sophia Antipolis 2323 Chemin St Bernard 06225 Vallauris, Cedex FRANCE EMail: Delphine.Kaplan@activia.net Martin May ActiVia Networks Space Antipolis 5 Parc de Sophia Antipolis 2323 Chemin St Bernard 06225 Vallauris, Cedex FRANCE EMail: martin.may@activia.net Appendix A. Acknowledgements To be provided. Cain, et. al. Expires August 25, 2002 page [22] Internet-Draft CNAP August 2002 Full Copyright Statement Copyright (C) The Internet Society ( 2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Cain, et. al. Expires August 25, 2002 page [23]