Please publish the following as an internet draft
thanks
abbie
Network Working Group November 2001
Internet-Draft Brad Cain
Expires: May 14, 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)
<draft-cain-cdi-cnap-00.txt>
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 October 30, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). 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 May 14, 2002 page [1]
Internet-Draft CNAP November 2001
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 May 14, 2002 page [2]
Internet-Draft CNAP November 2001
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) as described in this document.
Cain, et. al. Expires May 14, 2002 page [3]
Internet-Draft CNAP November 2001
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. However, this document only
focus on CNAP that is used for the advertisement of CN content
and network availability.
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 information two types of information with other
neighbor CNs. These 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. CNAP is a
simple advertisement protocol intended to be used between CNs for
the purpose of exchanging this information.
Cain, et. al. Expires May 14, 2002 page [4]
Internet-Draft CNAP November 2001
2.3.1 CIG Abstract Model
The CNAP protocol runs on CIGs, which is the interconnection
device that is dedicated to interconnecting CNs. A CIGs contains
several basic components that are depicted in Figure 1. We now
briefly describe each of these abstract components:
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
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 May 14, 2002 page [5]
Internet-Draft CNAP November 2001
Each CNs has to keep track of the list 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 the content. An example of this information is
information 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).
Cain, et. al. Expires May 14, 2002 page [6]
Internet-Draft CNAP November 2001
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.
- Other 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
decision. These are keyed on IP prefix/length pairs and
contain metrics from a CN to those prefixes.
Cain, et. al. Expires May 14, 2002 page [7]
Internet-Draft CNAP November 2001
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 similar to
the Autonomous System (AS) identifier used in inter-domain IP
routing.
Initially, CNAP is specified to be used with 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:
- Local CNAS
- Local CIG IP address
- Neighbor CNAS
- Neighbor CIG IP address
- Security credentials
- And any advertisement filtering policies
Cain, et. al. Expires May 14, 2002 page [8]
Internet-Draft CNAP November 2001
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. This
allows easy of debugging and makes CNAP flexible and extensible.
The following are used within CNAP messages:
CNAPurl = url-parameters
protocolversion = 1*3DIGIT ; 0 to 255
cnas = 1*5DIGIT ; 0 to 99999
holdtime = 1*3DIGIT ; 0 to 255
distrib-level-types = ("multiple" | "single")
rrs-type = ("dns-cname")
IPv4address = 1*digit "." 1*digit "." 1*digit "."
1*digit
IPv4mask = 1*digit
other-param = (token | (token "=" (token | quoted-
string )))
advert-type = ("area" | "content")
content-as-path = *( (1*5DIGIT) [","])
area-list = *( (IPv4address "&" IPv4mask ) [","] )
error-data = *(alphanum)
status-type = ("add" | "withdraw")
region-id-list = *( (1*5DIGIT) [","])
rdir-value = *(alphanum)
Each CNAP message contains a small one-line header that includes
the CNAP message type. Each message type has its own unique
header.
generic-message = start-line
[message-header]
CRLF
Cain, et. al. Expires May 14, 2002 page [9]
Internet-Draft CNAP November 2001
message-header = ( open-header
| notification-header
| advertisement-header )
Header fields ("open-header", "notification-header",
"advertisement-header") 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 = <the OCTETs making up the field-value and
consisting of either TEXT-UTF8 or combinations
of token, separators and quoted string>
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.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-Levels
| RRS-Types
Cain, et. al. Expires May 14, 2002 page [10]
Internet-Draft CNAP November 2001
Protocol-Version: CNAP protocol version number running on the
CIG gateway.
Protocol-Version = "Protocol-Version" ":" protocolversion
Node-ID: The Node ID is an unique IP address of the CIG.
Node-ID = "Node-ID" ":" IPv4Address
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: Keepalives expected in this interval.
Holdtime = "Holdtime" ":" holdtime
Distrib-Levels: Number of levels supported for request
routing for this CN.
Distrib-Levels = "Distrib-Levels" ":" distrib-level-type
RRS-Types: list of RRS types supported by this CN.
RRS-Types = "RRS-Types" ":" *(rrs-type)
CNAPabilities: list of optional CNAPabilities supported by
the CN.
CNAPabilities = *(CNAPability)
3.5.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.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 May 14, 2002 page [11]
Internet-Draft CNAP November 2001
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
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)
The following are currently defined error-codes
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.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
RegionIDs. A RegionID is a 16-bit unsigned integer (Editor Note:
Actual size is TBD) assigned to one or more IP prefixes. If a
Content ADVERTISE message contains RegionIDs, it means "this
content is available in these areas with these RegionIDs".
Cain, et. al. Expires May 14, 2002 page [12]
Internet-Draft CNAP November 2001
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 CONTENTAS 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 CONTENTAS
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.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" ":" *( (CNAPurl) [","] )
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
Cain, et. al. Expires May 14, 2002 page [13]
Internet-Draft CNAP November 2001
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
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
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.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
Cain, et. al. Expires May 14, 2002 page [14]
Internet-Draft CNAP November 2001
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 16-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
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.
Cain, et. al. Expires May 14, 2002 page [15]
Internet-Draft CNAP November 2001
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.
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.
Cain, et. al. Expires May 14, 2002 page [16]
Internet-Draft CNAP November 2001
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.
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 May 14, 2002 page [17]
Internet-Draft CNAP November 2001
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 14, March 1997.
[3] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CDN
Peering Architectural Overview", January 2001.
[4] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", January 2001.
[5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
January 2001.
[6] Cain, B., Spatscheck, O., May, M. and A. Barbir,
"Request Routing Requirements for Content
Internetworking", January 2001.
[7] Gilletti, D., Nair, R., Scharber, J. and J. Guha,
"Accounting Requirements for CDN Internetworking",
January 2001.
[8] Amini, L., Spatscheck, O. and S. Thomas, "Distribution
Requirements for Content Delivery Internetworking",
January, 2001.
[9] Day, M., Cain, B. and G. Tomlinson, "A Model for Content
Distribution Internetworking", January 2001.
[10] Day, M., Cain, B. and G. Tomlinson, "Content
Distribution Network Peering Scenarios", January 2001.
[11] Kent, S., Atkinson, R. and G. Tomlinson, "Security
Architecture for the Internet Protocol", January 2001.
[12] Cain et al, "Known CDN Request-Routing Mechanisms",
draft-cain-cdnp-known-request-routing-04.txt (work in
progress, November 2001).
Cain, et. al. Expires May 14, 2002 page [18]
Internet-Draft CNAP November 2001
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 May 14, 2002 page [19]
Internet-Draft CNAP November 2001
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 May 14, 2002 page [20]
Internet-Draft CNAP November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 May 14, 2002 page [21]