[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-cain-cdi-cnap-02.txt
Please publish the attached as an Internet-Draft.
Thanks
Kobus
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)
<draft-cain-cdi-cnap-02.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 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 OCTETs making up the field-value and
consisting of either TEXT-UTF8 or combinations
of token, separators and quoted string>
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