draft-ietf-cdni-footprint-capabilities-semantics-11.txt   draft-ietf-cdni-footprint-capabilities-semantics-12.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: September 5, 2016 Neustar Expires: September 9, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
March 4, 2016 March 8, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-11 draft-ietf-cdni-footprint-capabilities-semantics-12
Abstract Abstract
This document captures the semantics of the "Footprint and This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e., the desired meaning of "Footprint" and interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and "Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries further defines a Base Advertisement Object, the necessary registries
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2016. This Internet-Draft will expire on September 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2. Design Decisions for Footprint and Capabilities . . . . . . . 4 2. Design Decisions for Footprint and Capabilities . . . . . . . 4
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7 2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 11 5. Semantics for Capabilities Advertisement . . . . . . . . . . 11
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Delivery Protocol Capability Object . . . . . . . . . . . 14 7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15
7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15
7.4. Redirection Mode Capability Object . . . . . . . . . . . 15 7.4. Redirection Mode Capability Object . . . . . . . . . . . 15
7.5. Capability Advertisement Object Serialization . . . . . . 15 7.5. Capability Advertisement Object Serialization . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16
8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17 8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17
8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17
8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
skipping to change at page 4, line 27 skipping to change at page 4, line 27
2. Design Decisions for Footprint and Capabilities 2. Design Decisions for Footprint and Capabilities
A large part of the difficulty in discussing the FCI lies in A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint understanding what exactly is meant when trying to define footprint
in terms of "coverage" or "reachability." While the operators of in terms of "coverage" or "reachability." While the operators of
CDNs pick strategic locations to situate caches, a cache with a CDNs pick strategic locations to situate caches, a cache with a
public IPv4 address is reachable by any endpoint on the Internet public IPv4 address is reachable by any endpoint on the Internet
unless some policy enforcement precludes the use of the cache. unless some policy enforcement precludes the use of the cache.
Some CDNs aspire to cover the entire world, which we will henceforth Some CDNs aspire to cover the entire world; we refer to these as
call global CDNs. The footprint advertised by such a CDN in the CDNI global CDNs. The footprint advertised by such a CDN in the CDNI
environment would, from a coverage or reachability perspective, environment would, from a coverage or reachability perspective,
presumably cover all prefixes. Potentially more interesting for CDNI presumably cover all prefixes. Potentially more interesting for CDNI
use cases, however, are CDNs that claim a more limited coverage, but use cases, however, are CDNs that claim a more limited coverage, but
seek to interconnect with other CDNs in order to create a single CDN seek to interconnect with other CDNs in order to create a single CDN
fabric which shares resources. fabric which shares resources.
Futhermore, not all capabilities need to be footprint restricted. Furthermore, not all capabilities need to be footprint restricted.
Depending upon the use case, the optimal semantics of "footprints Depending upon the use case, the optimal semantics of "footprints
with capability attributes" vs. "capabilities with footprint with capability attributes" vs. "capabilities with footprint
restrictions" are not clear. restrictions" are not clear.
The key to understanding the semantics of footprint and capability The key to understanding the semantics of footprint and capability
advertisement lies in understand why a dCDN would advertise a limited advertisement lies in understand why a dCDN would advertise a limited
coverage area, and how a uCDN would use such advertisements to decide coverage area, and how a uCDN would use such advertisements to decide
among one of several dCDNs. The following section will discuss some among one of several dCDNs. The following section will discuss some
of the trade-offs and design decisions that need to be decided upon of the trade-offs and design decisions that need to be decided upon
for the CDNI FCI. for the CDNI FCI.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
4. Semantics for Footprint Advertisement 4. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and Roughly speaking, "footprint" can be defined as "ability and
willingness to serve" by a downstream CDN. However, in addition to willingness to serve" by a downstream CDN. However, in addition to
simple "ability and willingness to serve", the uCDN could want simple "ability and willingness to serve", the uCDN could want
additional information to make a dCDN selection decision, e.g., "how additional information to make a dCDN selection decision, e.g., "how
well" a given dCDN can actually serve a given end user request. The well" a given dCDN can actually serve a given end user request. The
"ability and willingness" to serve SHOULD be distinguished from the "ability and willingness" to serve SHOULD be distinguished from the
subjective qualitative measurement of "how well" it was served. One subjective qualitative measurement of "how well" it was served. One
can imagine that such additional information is implicitly associated can imagine that such additional information is implicitly associated
with a given footprint, e.g., due to contractual agreements (e.g., with a given footprint, due to contractual agreements, SLAs, business
SLAs), business relationships, or perceived dCDN quality in the past. relationships, or past perceptions of dCDN quality. As an
As an alternative, such additional information could also be alternative, such additional information could also be explicitly
explicitly tagged along with the footprint. tagged along with the footprint.
It is reasonable to assume that a significant part of the actual It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between footprint advertisement will happen in contractual agreements between
participating CDNs, i.e., prior to the advertisement phase using the participating CDNs, prior to the advertisement phase using the CDNI
CDNI FCI. The reason for this assumption is that any contractual FCI. The reason for this assumption is that any contractual
agreement is likely to contain specifics about the dCDN coverage agreement is likely to contain specifics about the dCDN coverage
(i.e., the dCDN footprint) to which the contractual agreement (footprint) to which the contractual agreement applies. In
applies. In particular, additional information to judge the delivery particular, additional information to judge the delivery quality
quality associated with a given dCDN footprint might be defined in associated with a given dCDN footprint might be defined in
contractual agreements (i.e. outside of the CDNI FCI). Further, one contractual agreements, outside of the CDNI FCI. Further, one can
can assume that dCDN contractual agreements about the delivery assume that dCDN contractual agreements about the delivery quality
quality associated with a given footprint will probably be based on associated with a given footprint will probably be based on high-
high-level aggregated statistics (i.e., not too detailed). level aggregated statistics and not too detailed.
Given that a large part of footprint advertisement will actually Given that a large part of footprint advertisement will actually
happen in contractual agreements, the semantics of CDNI footprint happen in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates still needs to be advertised by the CDNI FCI? For instance, updates
about temporal failures of part of a footprint can be useful about temporal failures of part of a footprint can be useful
information to convey via the CDNI request routing interface. Such information to convey via the CDNI request routing interface. Such
information would provide updates on information previously agreed in information would provide updates on information previously agreed in
contracts between the participating CDNs. In other words, the CDNI contracts between the participating CDNs. In other words, the CDNI
FCI is a means for a dCDN to provide changes/updates regarding a FCI is a means for a dCDN to provide changes/updates regarding a
skipping to change at page 9, line 43 skipping to change at page 9, line 43
coverage/reachability refers to a set of prefixes, a geographic coverage/reachability refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/ region, or similar boundary. The dCDN claims that it can cover/
reach 'end user requests coming from this footprint'. reach 'end user requests coming from this footprint'.
o Footprint could be defined based on "resources", where resources o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from location of surrogates/resources). The dCDN claims that 'from
this footprint' it can serve incoming end user requests. this footprint' it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated For each of these footprint types, there are capabilities associated
with a given footprint, i.e., the capabilities (e.g., delivery with a given footprint:
protocol, redirection mode, metadata) supported in the coverage area
for a "coverage/reachability" defined footprint, or the capabilities o capabilities such as delivery protocol, redirection mode, and
of resources (e.g., delivery protocol, redirection mode, metadata metadata, which are supported in the coverage area for a
support) for a "resource" defined footprint. "coverage/reachability" defined footprint, or
o capabilities of resources, such as delivery protocol, redirection
mode, and metadata, which apply to a "resource" defined footprint.
It seems clear that "coverage/reachability" types of footprint MUST It seems clear that "coverage/reachability" types of footprint MUST
be supported within CDNI. The following such types of footprint are be supported within CDNI. The following such types of footprint are
mandatory and MUST be supported by the CDNI FCI: mandatory and MUST be supported by the CDNI FCI:
o List of ISO Country Codes o List of ISO Country Codes
o List of AS numbers o List of AS numbers
o Set of IP-prefixes o Set of IP-prefixes
skipping to change at page 10, line 41 skipping to change at page 10, line 45
dCDN: A dCDN footprint advertisement tells the uCDN the limitations dCDN: A dCDN footprint advertisement tells the uCDN the limitations
for delegating a request to the dCDN. For IP prefixes or ASN(s), the for delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it SHOULD consider the dCDN a footprint signals to the uCDN that it SHOULD consider the dCDN a
candidate only if the IP address of the request routing source falls candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN ranges are in a particular ASN. Similarly, for country codes a uCDN
SHOULD only consider the dCDN a candidate if it covers the country of SHOULD only consider the dCDN a candidate if it covers the country of
the request routing source. The CDNI specifications do not define the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive, i.e., the source. Multiple footprint constraints are additive: the
advertisement of different types of footprint narrows the dCDN advertisement of different types of footprint narrows the dCDN
candidacy cumulatively. candidacy cumulatively.
In addition to these mandatory "coverage/reachability" types of In addition to these mandatory "coverage/reachability" types of
footprint, other optional "coverage/reachability" types of footprint footprint, other optional "coverage/reachability" types of footprint
or "resource" types of footprint MAY be defined by future or "resource" types of footprint MAY be defined by future
specifications. To facilitate this, a clear process for specifying specifications. To facilitate this, a clear process for specifying
optional footprint types in an IANA registry is specified in the CDNI optional footprint types in an IANA registry is specified in the CDNI
Metadata Footprint Types registry (defined in the CDNI Metadata Metadata Footprint Types registry (defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata]). Interface document [I-D.ietf-cdni-metadata]).
skipping to change at page 12, line 5 skipping to change at page 12, line 10
to agree on a subset and the precise metrics to be used. Second, and to agree on a subset and the precise metrics to be used. Second, and
perhaps more importantly, it seems infeasible to specify such highly perhaps more importantly, it seems infeasible to specify such highly
dynamically changing capabilities and the corresponding metrics dynamically changing capabilities and the corresponding metrics
within the CDNI charter time-frame. within the CDNI charter time-frame.
Useful capabilities refer to information that does not change highly Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if on a particular dCDN for a given end user request. For instance, if
an end user request concerns the delivery of a video file with a an end user request concerns the delivery of a video file with a
certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN
has the capabilitity of supporting this delivery protocol. has the capability of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs, will happen in contractual agreements between participating CDNs,
i.e., prior to the advertisement phase using the CDNI FCI. The role i.e., prior to the advertisement phase using the CDNI FCI. The role
of capability advertisement is hence rather to enable the dCDN to of capability advertisement is hence rather to enable the dCDN to
update a uCDN on changes since a contract has been set up (e.g., in update a uCDN on changes since a contract has been set up (e.g., in
case a new delivery protocol is suddenly being added to the list of case a new delivery protocol is suddenly being added to the list of
supported delivery protocols of a given dCDN, or in case a certain supported delivery protocols of a given dCDN, or in case a certain
delivery protocol is suddenly not being supported anymore due to delivery protocol is suddenly not being supported anymore due to
skipping to change at page 12, line 44 skipping to change at page 12, line 49
understanding what concrete capabilities are needed to facilitate CDN understanding what concrete capabilities are needed to facilitate CDN
Interconnection. Interconnection.
Under the above considerations, the following capabilities seem Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e., ones that are needed in any case useful as 'base' capabilities, i.e., ones that are needed in any case
and therefore constitute mandatory capabilities that MUST be and therefore constitute mandatory capabilities that MUST be
supported by the CDNI FCI: supported by the CDNI FCI:
o Delivery Protocol (e.g., HTTP vs. RTMP) o Delivery Protocol (e.g., HTTP vs. RTMP)
o Acquisition Protocol (for aquiring content from a uCDN) o Acquisition Protocol (for acquiring content from a uCDN)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [RFC7336]) discussed in [RFC7336])
o CDNI Logging (i.e., supported logging fields) o CDNI Logging (i.e., supported logging fields)
o CDNI Metadata (i.e., supported Generic Metadata types) o CDNI Metadata (i.e., supported Generic Metadata types)
It is not feasible to enumerate all the possible options for the It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, FCI specification with defining each supported capability. Instead,
the CDNI FCI specification SHOULD define a generic protocol for the CDNI FCI specification SHOULD define a generic protocol for
conveying any capability information (e.g. with common encoding, conveying any capability information (e.g. with common encoding,
error handling, and security mechanism; further requirements for the error handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in [RFC7337]). In this CDNI FCI Advertisement Interface are listed in [RFC7337]). In this
respect, it seems reasonable to define a registry which initially respect, it seems reasonable to define a registry which initially
skipping to change at page 13, line 36 skipping to change at page 13, line 41
be supported but would be redundant. CDNs SHOULD NOT advertise be supported but would be redundant. CDNs SHOULD NOT advertise
support for mandatory-to-implement logging fields. The following support for mandatory-to-implement logging fields. The following
logging fields are defined as optional in the CDNI Logging Interface logging fields are defined as optional in the CDNI Logging Interface
document [I-D.ietf-cdni-logging]: document [I-D.ietf-cdni-logging]:
o s-ccid o s-ccid
o s-sid o s-sid
The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does
not define any optional GenericMetadata types. Advertiseing support not define any optional GenericMetadata types. Advertising support
for mandatory-to-implement GenericMetadata types SHOULD be supported for mandatory-to-implement GenericMetadata types SHOULD be supported.
but would be redundant. CDNs SHOULD NOT advertise support for Advertisement of mandatory-to-implement GenericMetadata MAY be
mandatory-to-implement GenericMetadata types. necessary, e.g., to signal temporary outages and subsequent recovery,
however, it is expected that mandatory-to-implement GenericMetadata
will be supported and available in the typical case. In the typical
case, advertising support for mandatory-to-implement GenericMetadata
would be redundant, therefore, CDNs SHOULD NOT advertise support for
mandatory-to-implement GenericMetadata types by default.
6. Negotiation of Support for Optional Types of Footprint/Capabilities 6. Negotiation of Support for Optional Types of Footprint/Capabilities
The notion of optional types of footprint and capabilities implies The notion of optional types of footprint and capabilities implies
that certain implementations might not support all kinds of footprint that certain implementations might not support all kinds of footprint
and capabilities. Therefore, any FCI solution protocol MUST define and capabilities. Therefore, any FCI solution protocol MUST define
how the support for optional types of footprint/capabilities will be how the support for optional types of footprint/capabilities will be
negotiated between a uCDN and a dCDN that use the particular FCI negotiated between a uCDN and a dCDN that use the particular FCI
protocol. In particular, any FCI solution protocol MUST specify how protocol. In particular, any FCI solution protocol MUST specify how
to handle failure cases or non-supported types of footprint/ to handle failure cases or non-supported types of footprint/
skipping to change at page 17, line 15 skipping to change at page 17, line 25
[RFC Editor: Please replace RFCthis with the published RFC number for [RFC Editor: Please replace RFCthis with the published RFC number for
this document.] this document.]
8.1.1. CDNI FCI DeliveryProtocol Payload Type 8.1.1. CDNI FCI DeliveryProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported delivery protocols advertisement objects for supported delivery protocols
Interface: FCI Interface: FCI
Encoding: see Section 7 Encoding: see Section 7.2 and Section 7.5
8.1.2. CDNI FCI AcquisitionProtocol Payload Type 8.1.2. CDNI FCI AcquisitionProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported acquisition protocols advertisement objects for supported acquisition protocols
Interface: FCI Interface: FCI
Encoding: see Section 7 Encoding: see Section 7.3 and Section 7.5
8.1.3. CDNI FCI RedirectionMode Payload Type 8.1.3. CDNI FCI RedirectionMode Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported redirection modes advertisement objects for supported redirection modes
Interface: FCI Interface: FCI
Encoding: see Section 7 Encoding: see Section 7.4 and Section 7.5
8.2. Redirection Mode Registry 8.2. Redirection Mode Registry
The IANA is requested to create a new "CDNI Capabilities Redirection The IANA is requested to create a new "CDNI Capabilities Redirection
Modes" registry in the "Content Delivery Networks Interconnection Modes" registry in the "Content Delivery Networks Interconnection
(CDNI) Parameters" category. The "CDNI Capabilities Redirection (CDNI) Parameters" category. The "CDNI Capabilities Redirection
Modes" namespace defines the valid redirection modes that can be Modes" namespace defines the valid redirection modes that can be
advertised as supported by a CDN. Additions to the Redirection Mode advertised as supported by a CDN. Additions to the Redirection Mode
namespace conform to the "IETF Review" policy as defined in namespace conform to the "IETF Review" policy as defined in
[RFC5226]. [RFC5226].
 End of changes. 21 change blocks. 
38 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/