INTERNET-DRAFT CNAP Page 1 Network Working Group July 2002 Internet-Draft Brad Cain Expires: January 1, 2003 Cereva Networks Oliver Spatscheck Kobus van der Merwe 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 January 1, 2003. Copyright Notice Copyright (C) The Internet Society ( 2002). All Rights Reserved. Abstract The Content Network Advertisement Protocol (CNAP) is a protocol Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 2 Intended to facilitate the interconnection of Content Networks (CNs). 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. 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. 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 of 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. CNAP is used to advertise: - Advertisement of Content available within a CN using content advertisements. Content advertisements may include a number of attributes concerning the content. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 3 - 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. 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. This step is also called Request for Distribution. Request for distribution may involve the actual distribution of content to the target CN or it might only involve the exchange of enough information such that the target CN can retrieve the content when requested to serve it. 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 4 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 Network Advertisement Protocol (CNAP). The details of CNAP are described in this document. Note that a CN exchanges information about specific content only with CNs which requested the distribution of such content in the first place. 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 can be protocol driven. 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 make content available from the neighbor CDN. - 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 5 to a neighbor CN. 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. Information obtained through CNAP exchanges with other CNs is combined with similar information from the local CN to form a database of content that is either available in the local CN or in one of the peer CNs. Local policy is applied to this information to determine a local forwarding information base which drives the local RRS. The information in the forwarding information base indicates to the RRS system of the local CN when requests to specific 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. - 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 6 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 could potentially be exchanged using CNAP. Information exchanged between CNs using CNAP is communicated on a peer-to-peer basis. That is, a CIG in CN A uses CNAP to report to a peer (in CN B) regarding the status of content in CN A that the peer previously requested to be distributed in that CN. This means that policies and decisions about where content should be distributed to is made in the Content Distribution Protocol. CNAP only reports on the status of such content in a particular CN. 3.2 Information Types CNAP advertises information for the following purposes: - The readiness (or not) of a CN to serve content - How the requesting 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. - 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 7 decision. These are keyed on IP prefix/length pairs and contain metrics from a CN to those prefixes. Separating content and area advertisements allows for this information to be distributed in a scalable manner. For all content that is available from the same coverage regions, an single area advertisement can be exchanged once and then simply referenced in subsequent content advertisements. 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. A Content Autonomous System is a single administrative CN. The Content Autonomous System is included in a number of CNAP protocol messages. 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 [14]. It includes four types of messages: OPEN, KEEPALIVE, NOTIFY, ADVERTISE. 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 8 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: - Local CNAS - Local CIG IP address - Neighbor CNAS - Neighbor CIG IP address - Security credentials 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 ESTABLISHED 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*8DIGIT ; 0 TO 255 CNAS = 1*16DIGIT ; HOLDTIME = 1*8DIGIT ; 0 TO 255 RRS-TYPE = ("DNS-CNAME") IP-VERSION = ("4" | "6") IPV4-ADDRESS = 1*8DIGIT "." 1*8DIGIT "." 1*8DIGIT "."1*8DIGIT IPV4-MASK = 1*5DIGIT ; 0 TO 32 IPV6-PARAMETER = TBD OTHER-PARAM = (token | (token "=" (token | QUOTED- STRING))) ADVERT-TYPE = ("AREA" | "CONTENT") AREA-LIST = *((IPV4-ADDRESS "&" IPV4-MASK)[","]) ERROR-DATA = *(ALPHANUM) STATUS-TYPE = ("READY" | "WITHDRAW") Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 9 REGION-ID-LIST = *(REGION-ID [","]) REGION-ID = 1*32DIGIT RDIR-VALUE = *(ALPHANUM) In general, CNAP messages consist of a method-line, a message-header and an empty line indicating the end of the message: generic-message = method-line message-header CRLF The method-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 Types (method-line) Each CNAP message starts with a single method-line defined by: method-line = Method CRLF Each method corresponds to a CNAP message type. The Method token is case-sensitive. Method = "OPEN" | "NOTIFY" | "ADVERTISE" | "KEEPALIVE" 3.5.2 Message Header Fields (message-header) The second line of each CNAP message is a message-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 [15]. 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. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 10 Message-header = field-name ":" [field-value] CRLF Field-name = token Field-value = *(field-content |LWS) Field-content = 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 | 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 - HOLDTIME A CIG calculates the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 11 received in the OPEN message. The Hold Time must be either zero or at least one minute. The calculated value indicates the maximum number of minutes that may elapse between the receipt of successive KEEPALIVE, and/or ADVERTISE messages, and initiates the Hold timer. A HOLDTIME of zero indicates that KEEPALIVE messages MUST NOT be sent and that the peers rely on another mechanism to determine liveness and/or reachibility. HOLDTIME = "HOLDTIME" ":" HOLDTIME - RRS-Types list of RRS types supported by this CN. RRS-TYPES = "RRS-TYPES" ":" *(RRS-TYPE) - CAPABILITIES List of optional CAPABILITIES supported by the CN. CAPABILITIES = *(CAPABILITIES) 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. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval. If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent, and relevant implementations have to rely on another keep-alive mechanism to determine if peers are reachable. 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 12 where, - ERROR-CODE Error code indicates the type of notification. Error-Code = "Error-Code" ":" 3DIGIT - 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 - Message Header Error 2 - OPEN Message Error 3 - ADVERTISE Message Error 4 - CONTENT Message Error 5 - 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: Message Header Error Subcodes 1 - Unsupported method data: the method name 2 - Missing Field data: the message type, subtype if present, and the field which is missing 3 - Unknown Message Field data: the message type, subtype if present, and the name of the field 4 - Invalid Field Value Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 13 data: the message type, subtype if present, and the name and value of the field 5 - Unexpected Message Header data: the expected message type and the effective one OPEN Error Subcodes 1 - Unsupported Protocol Version data: largest version supported 2 - Bad Node Identifier data: the unauthorized node identifier 3 - Bad Peer CNAS data: the unauthorized CNAS number 4 - Unacceptable Hold Time 5 - Unsupported RRS type data: the RRS type ADVERTISE Error Subcodes 1 - Unsupported Advertisement Type data: the type 2 - Invalid Status data: the advertisement type and the value of the status field 3 - Bad RID data: the advertisement type and the unauthorized RID present in the region list CONTENT Error Subcodes 1 - Unsupported Redirection Type data: the redirection type 2 - Invalid Redirection Value data: the type and value of the redirection AREA Error Subcodes 1 - Bad Prefix data: the invalid prefix present in the area set 2 - Unsupported Metric Type data: the metric type 3 - Invalid Metric Value data: the type and value of the metric [Note: Malformed Message Header ? (if method does not correspond to message header, advertisement type does not correspond to the effective type, status of adverstisement does not Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 14 correspond to effective status, etc.) ] 3.5.2.4 ADVERTISE ADVERTISE messages contains the actual content and CN information respectively in "Content" and "Area" advertisements. They are used to advertise positive status as well as to withdraw information. Area ADVERTISE messages convey details about regions of the Internet that the CN has coverage for (can serve content to). Content ADVERTISE messages convey details about the availability of content and how to access such content. By linking Area and Content advertisements a CN can therefore advertise details abouts its ability to serve certain content to certain parts of the Internet. Content and Area ADVERTISE messages are "linked" through Region IDs (RIDs). A RID is a 32-bit unsigned integer assigned to one or more IP prefixes. If a Content ADVERTISE message contains RIDs, it means "this content is available in these areas with these RIDs". Editor Note: Need to define RegionIDs. Editor Note: Need to properly define TTL. advertisement-header = ADVERTISE-TYPE | (AREA-HEADER | CONTENT-HEADER) - ADVERTISE-TYPE This specifies the type of advertisement. ADVERTISE-TYPE = "ADVERTISE-TYPE" ":" ADVERT-TYPE 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 15 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) [","] ) - 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 32-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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 16 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, - 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. This field specifies the time when the withdraw will take effect in minutes relative to the time the message is received. 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 17 - 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 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 18 When any of the conditions described in this section are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the CNAP connection is closed. If no Error Subcode is specified, then a zero must be used. Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error is empty. 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 with Error Code Cease and move to the Idle state. A connection collision with a session in the OpenConfirm state (or in OpenSent state if the local system knows the CIG Identifier of the peer by external means), should retain only the connection initiated by the CIG with the higher-valued CIG node identifier (treating them as 4-octet - or 16-octet - long unsigned integers). 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. 3.6.3 Hold Timer Expired error handling. If a system does not receive successive KEEPALIVE and/or ADVERTISE and/or NOTIFICATION messages within the period specified in the Hold Time field of the OPEN message, then the NOTIFICATION message with Hold Timer Expired Error Code must be sent and the CNAP connection closed. 3.6.4 Finite State Machine error handling. Any error detected by the CNAP Finite State Machine (e.g., receipt of an unexpected event) is indicated by sending the NOTIFICATION message with Error Code Finite State Machine Error. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 19 3.6.5 Cease. In absence of any fatal errors (that are indicated in this section), a CNAP peer may choose at any given time to close its CNAP connection by sending the NOTIFICATION message with Error Code Cease. However, the Cease NOTIFICATION message must not be used when a fatal error indicated by this section does exist. 3.6.5 Notification. Any error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. 3.7 Finite State Machine State is defined on a per peer basis, where a peer is a Content Internetworking Gateway. When a state other than Idle changes to Idle state, this implies that all resources allocated for the session are released and the transport connections are closed. 3.7.1 States The same states as in BGP are defined. Initially CNAP is in the Idle state. Idle state: In this state CNAP refuses all incoming CNAP connections. No resources are allocated to the peer. In response to the Start event (initiated by either system or operator) the local system initializes all CNAP resources, starts the ConnectRetry timer, initiates a transport connection to other peer CIG, while listening for connection that may be initiated by the remote peer CIG, and changes its state to Connect. The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization. If a CIG detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent CNAP errors may result in persistent flapping of the CIG. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 20 are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry up to a maximum of 10 minutes. Any other event received in the Idle state is ignored. Connect state: In this state CNAP is waiting for the transport protocol connection to be completed. If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, and changes its state to OpenSent. If the transport protocol connect fails (e.g., retransmission timeout), the local system restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote peer CIG, and changes its state to Active state. In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to other peer CIG, continues to listen for a connection that may be initiated by the remote peer CIG, and stays in the Connect state. Start event is ignored in the Active state. In response to any other event (initiated by either system or operator), the local system releases all CNAP resources associated with this connection and changes its state to Idle. Active state: In this state CNAP is trying to acquire a peer by initiating a transport protocol connection. If the transport protocol connection succeeds, the local system clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to other peer CIG, continues to listen for a connection that may be initiated by the remote peer CIG, and changes its state to Connect. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 21 If the local system detects that a remote peer is trying to establish CNAP connection to it, and the IP address of the remote peer is not an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, continues to listen for a connection that may be initiated by the remote peer CIG, and stays in the Active state. Start event is ignored in the Active state. In response to any other event (initiated by either system or operator), the local system releases all CNAP resources associated with this connection and changes its state to Idle. Whenever CNAP changes its state from OpenSent to Idle, it closes the CNAP (and transport-level) connection and releases all resources associated with that connection. OpenSent - An OPEN message has been sent In this state CNAP waits for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the CNAP message header checking or OPEN message checking detects an error, or a connection collision with one in Estabished state, the local system sends a NOTIFICATION message and changes its state to Idle. If there are no errors in the OPEN message, CNAP sends a KEEPALIVE message and sets a KeepAlive timer. The Hold Timer, which was originally set to a large value, is replaced with the negotiated Hold Time value. If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timer are not started. Finally, the state is changed to OpenConfirm. If a disconnect notification is received from the underlying transport protocol, the local system closes the CNAP connection, restarts the ConnectRetry timer, while continue listening for connection that may be initiated by the remote CNAP peer, and goes into the Active state. If the Hold Timer expires, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle. In response to the Stop event (initiated by either system or operator) the local system sends NOTIFICATION message with Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 22 Error Code Cease and changes its state to Idle. Start event is ignored in the OpenSent state. In response to any other event the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle. Whenever CNAP changes its state from OpenSent to Idle, it closes the CNAP (and transport-level) connection and releases all resources associated with that connection. OpenConfirm - OPEN messages exchanged and confirmation required In this state CNAP waits for a KEEPALIVE or NOTIFICATION message. If the local system receives a KEEPALIVE message, it changes its state to Established. If the Hold Timer expires before a KEEPALIVE message is received, the local system sends NOTIFICATION message with error code Hold Timer Expired and changes its state to Idle. If the local system receives a NOTIFICATION message, it changes its state to Idle. If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer. If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle. In response to the Stop event (initiated by either system or operator) the local system sends NOTIFICATION message with Error Code Cease and changes its state to Idle. Start event is ignored in the OpenConfirm state. In response to any other event the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle. Whenever CNAP changes its state from OpenConfirm to Idle, it closes the CNAP (and transport-level) connection and releases all resources associated with that connection. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 23 Established - Session is established In the Established state CNAP can exchange ADVERTISE (CONTENT and AREA), NOTIFICATION, and KEEPALIVE messages with its peer. If the local system receives an ADVERTISE or KEEPALIVE message, it restarts its Hold Timer, if the negotiated Hold Time value is non-zero. If the local system receives a NOTIFICATION message, it changes its state to Idle. If the local system receives an erroneous ADVERTISE message the local system sends a NOTIFICATION message and changes its state to Idle. If a disconnect notification is received from the underlying transport protocol, the local system changes its state to Idle. If the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and changes its state to Idle. If the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer. Each time the local system sends a KEEPALIVE or ADVERTISE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero. In response to the Stop event (initiated by either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle. Start event is ignored in the Established state. In response to any other event, the local system sends NOTIFICATION message with Error Code Finite State Machine Error and changes its state to Idle. Whenever CNAP changes its state from Established to Idle, it closes the CNAP (and transport-level) connection, releases all resources associated with that connection, and deletes all 3.7.2 State Table The following defines the state table. For each state, Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 24 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 Established state and do not cause a state change. The OPEN sent in the Idle state MUST be sent by the initiator of 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. The following table describes the state transitions of the CNAP FSM and the actions triggered by these transitions. It is obtained from the condensed version of the BGP FSM found in rfc1771/Appendix 1 by replacing "BGP" by "CNAP", and "UPDATE" by "ADVERTISE". CNAP States: 1 - Idle 2 - Connect 3 - Active 4 - OpenSent 5 - OpenConfirm 6 - Established CNAP Events: 1 - CNAP Start 2 - CNAP Stop 3 - CNAP Transport connection open 4 - CNAP Transport connection closed 5 - CNAP Transport connection open failed 6 - CNAP Transport fatal error 7 - ConnectRetry timer expired 8 - Hold Timer expired 9 - KeepAlive timer expired 10 - Receive OPEN message 11 - Receive KEEPALIVE message 12 - Receive ADVERTISE messages Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 25 13 - Receive NOTIFICATION message The following table describes the state transitions of the CNAP FSM and the actions triggered by these transitions. Event Actions Message Sent Next State -------------------------------------------------------------------- Idle (1) 1 Initialize resources none 2 Start ConnectRetry timer Initiate a transport connection others none none 1 Connect(2) 1 none none 2 3 Complete initialization OPEN 4 Clear ConnectRetry timer 5 Restart ConnectRetry timer none 3 7 Restart ConnectRetry timer none 2 Initiate a transport connection others Release resources none 1 Active (3) 1 none none 3 3 Complete initialization OPEN 4 Clear ConnectRetry timer 5 Close connection 3 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 26 Restart ConnectRetry timer 7 Restart ConnectRetry timer none 2 Initiate a transport connection others Release resources none 1 OpenSent(4) 1 none none 4 4 Close transport connection none 3 Restart ConnectRetry timer 6 Release resources none 1 10 Process OPEN is OK KEEPALIVE 5 Process OPEN failed NOTIFICATION 1 others Close transport connection NOTIFICATION 1 Release resources OpenConfirm (5) 1 none none 5 4 Release resources none 1 6 Release resources none 1 9 Restart KeepAlive timer KEEPALIVE 5 11 Complete initialization none 6 Restart Hold Timer 13 Close transport connection 1 Release resources others Close transport connection NOTIFICATION 1 Release resources Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 27 Established (6) 1 none none 6 4 Release resources none 1 6 Release resources none 1 9 Restart KeepAlive timer KEEPALIVE 6 11 Restart Hold Timer KEEPALIVE 6 12 Process ADVERTISE is OK ADVERTISE 6 Process ADVERTISE failed NOTIFICATION 1 13 Close transport connection 1 Release resources others Close transport connection NOTIFICATION 1 Release resources --------------------------------------------------------------------- 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 the paths represented by the associated AREAs will be deleted from local tables. 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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 28 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. 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. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 29 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. [14] Rekhter Y., Li T. "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995 [15] Crocker D.H., "Standard For The Format Of ARPA Internet Text Messages", RFC 822, August 1982 NOTES: [bec] took out global CN info in Capabilities; will use 0.0.0.0/0 to advertise metrics for entire CN (in area advertisement) [bec] message definitions still need some work; need to reconcile with RFC2396 and RFC822 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 30 [Delphine] NOTES: 1/ to be more readable (and consistent): should use upper cases for all field names of CNAP messages 2/ To avoid excessive route flapping a CIG which needs to withdraw a content on a given area and send an advertisement about on a new equivalent area shall combine them into the same ADVERTISE message -> not possible in actual CNAP framework. 3/ Items in the Appendix: a/ The suggested value for the Hold Time is 10 minutes. b/ The suggested value for the KeepAlive timer is 5 minutes. 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 Kobus van der Merwe AT&T Labs 180 Park Ave, Bldg 103 Florham Park, NJ 07932, US EMail: kobus@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 Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 31 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. 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. Cain, et. al. Expires January 1, 2003 INTERNET-DRAFT CNAP Page 32 Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Cain, et. al. Expires January 1, 2003