CDNI Logging Interface
draft-ietf-cdni-logging-26
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7937.
|
|
|---|---|---|---|
| Authors | François Le Faucheur , Gilles Bertrand , Iuniana Oprescu , Roy Peterkofsky | ||
| Last updated | 2016-05-25 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-15)
by Martin Thomson
Almost ready
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Kevin J. Ma | ||
| Shepherd write-up | Show Last changed 2015-02-04 | ||
| IESG | IESG state | Became RFC 7937 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Spencer Dawkins | ||
| Send notices to | "Kevin J. Ma" <kevin.j.ma@ericsson.com> | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-cdni-logging-26
Network Working Group Luca Martini (Ed.)
Internet Draft Cisco Systems Inc.
Expiration Date: December 2013
Intended status: Standards Track Matthew Bocci (Ed.)
Florin Balus (Ed.)
Alcatel-Lucent
June 19, 2013
Dynamic Placement of Multi Segment Pseudowires
draft-ietf-pwe3-dynamic-ms-pw-17.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 December 19, 2013
Abstract
There is a requirement for service providers to be able to extend the
reach of pseudowires (PW) across multiple Packet Switched Network
domains. A Multi-Segment PW is defined as a set of two or more
contiguous PW segments that behave and function as a single point-
to-point PW. This document describes extensions to the PW control
protocol to dynamically place the segments of the multi segment
pseudowire among a set of Provider Edge (PE) routers.
Martini, et al. [Page 1]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
Table of Contents
1 Major Co-authors ..................................... 3
2 Acknowledgements ..................................... 3
3 Introduction ......................................... 3
3.1 Scope ................................................ 3
3.2 Specification of Requirements ........................ 3
3.3 Terminology .......................................... 4
3.4 Architecture Overview ................................ 4
4 Applicability ........................................ 6
4.1 Changes to Existing PW Signaling ..................... 6
5 PW Layer 2 Addressing ................................ 6
5.1 Attachment Circuit Addressing ........................ 6
5.2 S-PE Addressing ...................................... 7
6 Dynamic Placement of MS-PWs .......................... 7
6.1 Pseudowire Routing Procedures ........................ 8
6.1.1 AII PW Routing Table Lookup Aggregation Rules ........ 8
6.1.2 PW Static Route ...................................... 9
6.1.3 Dynamic Advertisement with BGP ....................... 9
6.2 LDP Signaling ........................................ 10
6.2.1 MS-PW Bandwidth Signaling ............................ 10
6.2.2 Equal Cost Multi Path (ECMP) in PW Routing ........... 12
6.2.3 Active/Passive T-PE Election Procedure ............... 12
6.2.4 Detailed Signaling Procedures ........................ 13
7 Failure Handling Procedures .......................... 14
7.1 PSN Failures ......................................... 14
7.2 S-PE Specfic Failures ................................ 14
7.3 PW Reachability Changes .............................. 15
8 Operations and Maintenance (OAM) ..................... 16
9 Security Considerations .............................. 16
10 IANA Considerations .................................. 16
10.1 LDP TLV TYPE NAME SPACE .............................. 17
10.2 LDP Status Codes ..................................... 17
10.3 BGP SAFI ............................................. 17
11 Normative References ................................. 17
12 Informative References ............................... 18
13 Author's Addresses ................................... 18
Martini, et al. [Page 2]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
1. Major Co-authors
The editors gratefully acknowledge the following additional co-
authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan,
Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff
Sugimoto.
2. Acknowledgements
The editors also gratefully acknowledge the input of the following
people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile
Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada.
3. Introduction
3.1. Scope
[RFC5254] describes the service provider requirements for extending
the reach of pseudowires across multiple PSN domains. This is
achieved using a Multi-segment Pseudowire (MS-PW). An MS-PW is
defined as a set of two or more contiguous PW segments that behave
and function as a single point-to-point PW. This architecture is
described in [RFC5659].
The procedures for establishing PWs that extend across a single PSN
domain are described in [RFC4447], while procedures for setting up
PWs across multiple PSN domains, or control plane domains are
described in [RFC6073].
The purpose of this document is to specify extensions to the
pseudowire control protocol [RFC4447], and [RFC6073] procedures, to
enable multi- segment PWs to be dynamically placed. The proposed
procedures follow the guidelines defined in [RFC5036] and enable the
reuse of existing TLVs,
and procedures defined for SS-PWs in [RFC4447].
3.2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 's convenience.
The CDNI Logging File pull mechanisms is specified in Section 4.2.
An implementation of the CDNI Logging interface on the dCDN side (the
entity generating the CDNI Logging file) MUST support the server side
of the CDNI Logging feed (as specified in Section 4.1) and the server
side of the CDNI Logging pull mechanism (as specified in
Section 4.2).
An implementation of the CDNI Logging interface on the uCDN side (the
entity consuming the CDNI Logging file) MUST support the client side
Le Faucheur, et al. Expires November 26, 2016 [Page 42]
Internet-Draft CDNI Logging May 2016
of the CDNI Logging feed (as specified in Section 4.1) and the client
side of the CDNI Logging pull mechanism (as specified in
Section 4.2).
4.1. CDNI Logging Feed
The server-side implementation of the CDNI Logging feed MUST produce
an Atom feed [RFC4287]. This feed is used to advertise log files
that are available for the client-side to retrieve using the CDNI
Logging pull mechanism.
4.1.1. Atom Formatting
A CDNI Logging feed MUST be structured as an Archived feed, as
defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This
means it consists of a subscription document that is regularly
updated as new CDNI Logging Files become available, and information
about older CDNI Logging files is moved into archive documents. Once
created, archive documents are never modified.
Each CDNI Logging File listed in an Atom feed MUST be described in an
atom:entry container element.
The atom:entry MUST contain an atom:content element whose "src"
attribute is a link to the CDNI Logging File and whose "type"
attribute is the MIME Media Type indicating that the entry is a CDNI
logging file. This MIME Media Type is defined as "application/cdni"
(See [RFC7736]) with the Payload Type (ptype) parameter set to
"logging-file".
For compatibility with some Atom feed readers the atom:entry MAY also
contain an atom:link entry whose "href" attribute is a link to the
CDNI Logging File and whose "type" attribute is the MIME Media Type
indicating that the entry is a CDNI Logging File using the
"application/cdni" MIME Media Type with the Payload Type (ptype)
parameter set to "logging-file"(See [RFC7736]).
The URI used in the atom:id of the atom:entry MUST contain the UUID
of the CDNI Logging File.
The atom:updated in the atom:entry MUST indicate the time at which
the CDNI Logging File was last updated.
4.1.2. Updates to Log Files and the Feed
CDNI Logging Files MUST NOT be modified by the dCDN once published in
the CDNI Logging feed.
Le Faucheur, et al. Expires November 26, 2016 [Page 43]
Internet-Draft CDNI Logging May 2016
The frequency with which the subscription feed is updated, the period
of time covered by each CDNI Logging File or each archive document,
and timeliness of publishing of CDNI Logging Files are outside the
scope of the present document and are expected to be agreed upon by
uCDN and dCDN via other means (e.g., human agreement).
The server-side implementation MUST be able to set, and SHOULD set,
HTTP cache control headers on the subscription feed to indicate the
frequency at which the client-side is to poll for updates.
The client-side MAY use HTTP cache control headers (set by the
server-side) on the subscription feed to determine the frequency at
which to poll for updates. The client-side MAY instead, or in
addition, use other information to determine when to poll for updates
(e.g., a polling frequency that may have been negotiated between the
uCDN and dCDN by mechanisms outside the scope of the present document
and that is to override the indications provided in the HTTP cache
control headers).
The potential retention limits (e.g., sliding time window) within
which the dCDN is to retain and be ready to serve an archive document
is outside the scope of the present document and is expected to be
agreed upon by uCDN and dCDN via other means (e.g., human agreement).
The server-side implementation MUST retain, and be ready to serve,
any archive document within the agreed retention limits. Outside
these agreed limits, the server-side implementation MAY indicate its
inability to serve (e.g., with HTTP status code 404) an archive
document or MAY refuse to serve it (e.g., with HTTP status code 403
or 410).
4.1.3. Redundant Feeds
The server-side implementation MAY present more than one CDNI Logging
feed for redundancy. Each CDNI Logging File MAY be published in more
than one feed.
A client-side implementation MAY support such redundant CDNI Logging
feeds. If it supports redundant CDNI Logging feed, the client-side
can use the UUID of the CDNI Logging File, presented in the atom:id
element of the Atom feed, to avoid unnecessarily pulling and storing
a given CDNI Logging File more than once.
4.1.4. Example CDNI Logging Feed
Figure 8 illustrates an example of the subscription document of a
CDNI Logging feed.
Le Faucheur, et al. Expires November 26, 2016 [Page 44]
Internet-Draft CDNI Logging May 2016
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">CDNI Logging Feed</title>
<updated>2013-03-23T14:46:11Z</updated>
<id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id>
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="self" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="current" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1/201303231400"
rel="prev-archive" type="application/atom+xml" />
<generator version="example version 1">CDNI Log Feed
Generator</generator>
<author><name>dcdn.example</name></author>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:15:00</title>
<id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id>
<updated>2013-03-23T14:15:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323141500000000"
type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at
2013-03-23 14:15:00</summary>
</entry>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:30:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T14:30:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323143000000000"
type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at
2013-03-23 14:30:00</summary>
</entry>
...
<entry>
...
</entry>
</feed>
Figure 8: Example subscription document of a CDNI Logging Feed
Le Faucheur, et al. Expires November 26, 2016 [Page 45]quot;SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Martini, et al. [Page 3]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
3.3. Terminology
[RFC5659] provides terminology for multi-segment pseudowires.
This document defines the following additional terms:
- Source Terminating PE (ST-PE). A Terminating PE (T-PE), which
assumes the active signaling role and initiates the signaling for
multi-segment PW.
- Target Terminating PE (TT-PE). A Terminating PE (T-PE) that
assumes the passive signaling role. It waits and responds to the
multi-segment PW signaling message in the reverse direction.
- Forward Direction: ST-PE to TT-PE.
- Reverse Direction: TT-PE to ST-PE
- Forwarding Direction: Direction of control plane, signaling flow
- Pseudowire Routing (PW routing). The dynamic placement of the
segments that compose an MS-PW, as well as the automatic
selection of S-PEs.
3.4. Architecture Overview
The following figure describes the reference models which are derived
from [RFC5659] to support PW emulated services across multi-segment
PWs.
Martini, et al. [Page 4]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
Native |<-------------Pseudowire------------>| Native
Service | | Service
(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |-------|.....PW.Seg't1........PW Seg't3......|----------| |
| CE1| | | | | | | | | |CE2 |
| |-------|.....PW.Seg't2.......|PW Seg't4......|----------| |
+----+ | | |=========| |=========| | | +----+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<---------------- Emulated Service -------------------->|
Figure 1: PW switching Reference Model
Figure 1 shows the architecture for a simple multi-segment case. T-
PE1 and T-PE2 provide an emulated service to CE1 and CE2. These PEs
reside in different PSNs. A PSN tunnel extends from T-PE1 to S-PE1
across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2
across PSN2. PWs are used to connect the attachment circuits (ACs)
attached to T-PE1 to the corresponding AC attached to T-PE2. A PW on
the tunnel across PSN1 is connected to a PW in the tunnel across PSN2
at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and
T-PE2. S-PE1 is therefore the PW switching point and is referred to
as the switching provider edge (S-PE). PW Segment 1 and PW Segment 3
are segments of the same MS-PW while PW Segment 2 and PW Segment 4
are segments of another MS-PW. PW segments of the same MS-PW (e.g.,
PW segment 1 and PW segment 3) MUST be of the same PW type, and PSN
tunnels (e.g., PSN1 and PSN2) can be the same or different
technology. An S-PE switches an MS-PW from one segment to another
based on the PW identifiers. ( PWid , or AII ) How the PW PDUs are
switched at the S-PE depends on the PSN tunnel technology: in case of
an MPLS PSN to another MPLS PSN PW switching the operation is a
standard MPLS label switch operation.
Note that although Figure 1 only shows a single S-PE, a PW may
transit more one S-PE along its path. For instance, in the multi-
provider case, there can be an S-PE at the border of one provider
domain and another S-PE at the border of the other provider domain.
Martini, et al. [Page 5]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
4. Applicability
In this document we describe the case where the PSNs carrying the
SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions
with an IP PSN using L2TPv3 as described in [RFC6073] section 7.4 are
left for further study.
4.1. Changes to Existing PW Signaling
The procedures described in this document make use of existing LDP
TLVs and related PW signaling procedures described in [RFC4447] and
[RFC6073]. The following OPTIONAL TLVs are also defined:
- A Bandwidth TLV to address QoS Signaling requirements (see "MS-PW
Next Hop Bandwidth Signaling" section for details).
5. PW Layer 2 Addressing
Single segment pseudowires on an MPLS PSN can use attachment circuit
identifiers for a PW using FEC 129. In the case of a dynamically
placed MS-PW, there is a requirement for the identifiers for the
attachment circuits to be globally unique, for the purposes of
reachability and manageability of the PW. Referencing figure 1
above, individual globally unique addresses MUST be allocated to all
the ACs and S-PEs composing an MS-PW.
5.1. Attachment Circuit Addressing
The attachment circuit addressing is derived from [RFC5003] AII type
2 shown here:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (contd.) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AII type 2 based addressing schemes permit varying levels of AII
Martini, et al. [Page 6]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
summarization, thus reducing the scaling burden on PW routing. AII
Type 2 based PW addressing is suitable for point-to-point
provisioning models where it is not required to auto-discover address
at Target T-PE (knows the address in priori by provisioning).
Implementations of the following procedure MUST interpret the AII
type to determine the meaning of the address format of the AII,
irrespective of the number of segments in the MS-PW. All segments of
the PW MUST be signaled with same AII Type.
A unique combination of Global ID, Prefix, and AC ID parts of the AII
type 2 are assigned to each AC. In general, the same global ID and
prefix are be assigned for all ACs belonging to the same T-PE. This
is not a strict requirement, however. A particular T-PE might have
more than one prefix assigned to it, and likewise a fully qualified
AII with the same Global ID/Prefix but different AC IDs might belong
to different T-PEs.
For the purpose of MS-PWs, the AII MUST be globally unique across all
interconnected PW domains.
5.2. S-PE Addressing
Each S-PE MUST be uniquely addressable in terms of pseudowires in
order to populate the switching point PE TLV specified in [RFC6073].
For this purpose, at least one AI address of the format similar to
AII type 2 [RFC5003] composed of the Global ID, and Prefix part,
only, MUST be assigned to each S-PE.
If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned
with an S-PE address, then on receiving a Dynamic MS-PW label mapping
message the S-PE MUST return a Label Release with the
"LDP_RESOURCES_UNAVAILABLE" ( 0x38)" status code.
6. Dynamic Placement of MS-PWs
[RFC6073] describes a procedure for concatenating multiple
pseudowires together. This procedure requires each S-PE to be
manually configured with the information required for each segment of
the MS-PW. The procedures in the following sections describe a method
to extend [RFC6073] by allowing the automatic selection of pre-
defined S-PEs, and dynamically establishing a MS-PW between two T-
PEs.
Martini, et al. [Page 7]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
6.1. Pseudowire Routing Procedures
The AII type 2 described above contains a Global ID, Prefix, and AC
ID. The TAII is used by S-PEs to determine the next SS-PW destination
for LDP signaling.
Once an S-PE receives a MS-PW label mapping message containing a TAII
with an AII that is not locally present, the S-PE performs a lookup
in a PW AII routing table. If this lookup results in an IP address
for the next-hop PE with reachability information for the AII in
question, then the S-PE will initiate the necessary LDP messaging
procedure to set-up the next PW segment. If the PW AII routing table
lookup does not result in a IP address for a next-hop PE, the
destination AII has become unreachable, and the PW setup MUST fail.
In this case the next PW segment is considered un-provisioned, and a
label release MUST be returned to the T-PE with a status message of
"AII Unreachable".
If the TAI of a MS-PW label mapping message received by a PE contains
the prefix matching a locally-provisioned prefix on that PE, but an
AC ID that is not provisioned, then the LDP liberal label retention
procedures apply, and the label mapping message is retained.
To allow for dynamic end-to-end signaling of MS-PWs, information must
be present in S-PEs to support the determination of the next PW
signaling hop. Such information can be provisioned (equivalent to a
static route) on each S-PE, or disseminated via regular routing
protocols (e.g. BGP).
6.1.1. AII PW Routing Table Lookup Aggregation Rules
All PEs capable of dynamic MS-PW path selection MUST build a PW AII
routing table to be used for PW next-hop selection.
The PW addressing scheme (AII type 2 in [RFC5003]) consists of a
Global ID, a 32 bit prefix and a 32 bit Attachment Circuit ID.
An aggregation scheme similar to that used for classless IPv4
addresses can be employed. An (8 bits) length mask is specified as a
number ranging from 0 to 96 that indicates which Most Significant
Bits (MSB) are relevant in the address field when performing the PW
address matching algorithm.
0 31 32 63 64 95 (bits)
+-----------+--------+--------+
| Global ID | Prefix | AC ID |
+-----------+--------+--------+
Martini, et al. [Page 8]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
During the signaling phase, the content of the (fully qualified) TAII
type 2 field from the FEC129 TLV is compared against routes from the
PW Routing table. Similar with the IPv4 case, the route with the
longest match is selected, determining the next signaling hop and
implicitly the next PW Segment to be signaled.
6.1.2. PW Static Route
For the purpose of determining the next signaling hop for a segment
of the pseudowire, the PEs MAY be provisioned with fixed route
entries in the PW next hop routing table. The static PW entries will
follow all the addressing rules and aggregation rules described in
the previous sections. The most common use of PW static provisioned
routes is this example of the "default" route entry as follows:
Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling
Hop = S-PE1
6.1.3. Dynamic Advertisement with BGP
Any suitable routing protocol capable of carrying external routing
information MAY be used to propagate MS-PW path information among S-
PEs and T-PEs. However, T-PE, and S-PEs, MAY choose to use Border
Gateway Protocol (BGP) [RFC4760] to propagate PW address information
throughout the PSN.
Contrary to other l2vpn signaling methods that use BGP [RFC6074], in
the case of the dynamically placed MS-PW, the source T-PE knows a-
priori (by provisioning) the AC ID on the terminating T-PE to use in
signaling. Hence there is no need to advertise a "fully qualified&
Internet-Draft CDNI Logging May 2016
4.2. CDNI Logging File Pull
A client-side implementation of the CDNI Logging interface MAY pull,
at its convenience, a CDNI Logging File that is published by the
server-side in the CDNI Logging Feed (in the subscription document or
an archive document). To do so, the client-side:
o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232],
[RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP
versions (e.g., HTTP/2 [RFC7540]) and MAY negotiate which HTTP
version is actually used. This allows operators and implementers
to choose to use later versions of HTTP to take advantage of new
features, while still ensuring interoperability with systems that
only support HTTP/1.1.
o MUST use the URI that was associated to the CDNI Logging File
(within the "src" attribute of the corresponding atom:content
element) in the CDNI Logging Feed;
o MUST support exchange of CDNI Logging Files with no content
encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content
encoding (as defined in [RFC7230]) applied to the representation.
Note that a client-side implementation of the CDNI Logging interface
MAY pull a CDNI Logging File that it has already pulled.
The server-side implementation MUST respond to valid pull request by
a client-side implementation for a CDNI Logging File published by the
server-side in the CDNI Logging Feed (in the subscription document or
an archive document). The server-side implementation:
o MUST implement HTTP/1.1 to handle the client-side request and MAY
also support other HTTP versions (e.g., HTTP/2);
o MUST include the CDNI Logging File identified by the request URI
inside the body of the HTTP response;
o MUST support exchange of CDNI Logging Files with no content
encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content
encoding (as defined in [RFC7231]) applied to the representation.
Content negotiation approaches defined in [RFC7231] (e.g., using
Accept-Encoding request-header field or Content-Encoding entity-
header field) MAY be used by the client-side and server-side
Le Faucheur, et al. Expires November 26, 2016 [Page 46]
Internet-Draft CDNI Logging May 2016
implementations to establish the content-coding to be used for a
particular exchange of a CDNI Logging File.
Applying compression content encoding (such as "gzip") is expected to
mitigate the impact of exchanging the large volumes of logging
information expected across CDNs. This is expected to be
particularly useful in the presence of HTTP Adaptive Streaming (HAS)
which, as per the present version of the document, will result in a
separate CDNI Log Record for each HAS segment delivery in the CDNI
Logging File.
The potential retention limits (e.g., sliding time window, maximum
aggregate file storage quotas) within which the dCDN is to retain and
be ready to serve a CDNI Logging File previously advertised in the
CDNI Logging Feed is outside the scope of the present document and is
expected to be agreed upon by uCDN and dCDN via other means (e.g.,
human agreement). The server-side implementation MUST retain, and be
ready to serve, any CDNI Logging File within the agreed retention
limits. Outside these agreed limits, the server-side implementation
MAY indicate its inability to serve (e.g., with HTTP status code 404)
a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status
code 403 or 410).
5. Protocol for Exchange of CDNI Logging File During Collection
We note that, in addition to the CDNI Logging File exchange protocol
specified in Section 4, implementations of the CDNI Logging interface
may also support other mechanisms to exchange CDNI Logging Files. In
particular, such mechanisms might allow the exchange of the CDNI
Logging File to start before the file is fully collected. This can
allow CDNI Logging Records to be communicated by the dCDN to the uCDN
as they are gathered by the dCDN without having to wait until all the
CDNI Logging Records of the same logging period are collected in the
corresponding CDNI Logging File. This approach is commonly referred
to as "tailing" of the file.
Such an approach could be used, for example, to exchange logging
information with a significantly reduced time-lag (e.g., sub-minute
or sub-second) between when the event occurred in the dCDN and when
the corresponding CDNI Logging Record is made available to the uCDN.
This can satisfy log-consuming applications requiring extremely fresh
logging information such as near-real-time content delivery
monitoring. Such mechanisms are for further study and outside the
scope of this document.
Le Faucheur, et al. Expires November 26, 2016 [Page 47]
Internet-Draft CDNI Logging May 2016
6. IANA Considerations
When IANA allocates new extensions to CDNI Logging Directive Names
Registry, CDNI Logging File version Registry, CDNI Logging record-
type Registry or CDNI Logging fields Registry, IANA MUST take into
account that the directive names are case-insensitive as per the
basic ABNF([RFC5234]).
6.1. CDNI Logging Directive Names Registry
The IANA is requested to create a new "CDNI Logging Directive Names"
subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry.
The initial contents of the CDNI Logging Directives registry comprise
the names of the directives specified in Section 3.3 of the present
document, and are as follows:
+------------------------------+-----------+
| Directive Name | Reference |
+------------------------------+-----------+
| version | RFC xxxx |
| UUID | RFC xxxx |
| claimed-origin | RFC xxxx |
| established-origin | RFC xxxx |
| remark | RFC xxxx |
| record-type | RFC xxxx |
| fields | RFC xxxx |
| SHA256-hash | RFC xxxx |
+------------------------------+-----------+
Figure 9
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document]
Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226].
Directive names are to be allocated by IANA with a format of
NAMEFORMAT (see Section 3.1). All directive names defined in the
logging file are case-insensitive as per the basic ABNF([RFC5234]).
Each specification that defines a new CDNI Logging directive needs to
contain a description for the new directive with the same set of
information as provided in Section 3.3 (i.e., format, directive value
and occurrence).
Le Faucheur, et al. Expires November 26, 2016 [Page 48]
Internet-Draft CDNI Logging May 2016
6.2. CDNI Logging File version Registry
The IANA is requested to create a new "CDNI Logging File version"
subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry.
The initial contents of the CDNI Logging Logging File version
registry comprise the value "CDNI/1.0" specified in Section 3.3 of
the present document, and are as follows:
+-----------------+-----------+----------------------------------+
| version | Reference | Description |
+-----------------+-----------+----------------------------------+
| cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 |
| | | as specified in RFC xxxx |
+-----------------+-----------+----------------------------------+
Figure 10
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document]
Within the registry, version values are to be allocated by IANA
according to the "Specification Required" policy specified in
[RFC5226]. Version values are to be allocated by IANA with a format
of NAMEFORMAT (see Section 3.1). All version values defined in the
logging file are case-insensitive as per the basic ABNF([RFC5234]).
6.3. CDNI Logging record-types Registry
The IANA is requested to create a new "CDNI Logging record-types"
subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry.
The initial contents of the CDNI Logging record-types registry
comprise the names of the CDNI Logging Record types specified in
Section 3.4 of the present document, and are as follows:
+----------------------+-----------+---------------------------------+
| record-types | Reference | Description |
+----------------------+-----------+---------------------------------+
| cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 |
| | | for content delivery using HTTP |
+----------------------+-----------+---------------------------------+
Figure 11
Le Faucheur, et al. Expires November 26, 2016 [Page 49]
Internet-Draft CDNI Logging May 2016
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document]
Within the registry, record-types are to be allocated by IANA
according to the "Specification Required" policy specified in
[RFC5226]. Record-types are to be allocated by IANA with a format of
NAMEFORMAT (see Section 3.1). All record-types defined in the
logging file are case-insensitive as per the basic ABNF([RFC5234]).
Each specification that defines a new record-type needs to contain a
description for the new record-type with the same set of information
as provided in Section 3.4.1. This includes:
o a list of all the CDNI Logging fields that can appear in a CDNI
Logging Record of the new record-type
o for all these fields: a specification of the occurrence for each
Field in the new record-type
o for every newly defined Field, i.e., for every Field that results
in a registration in the CDNI Logging Field Names Registry
(Section 6.4): a specification of the field name, format and field
value.
6.4. CDNI Logging Field Names Registry
The IANA is requested to create a new "CDNI Logging Field Names"
subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry.
This registry is intended to be shared across the currently defined
record-type (i.e., cdni_http_request_v1) as well as potential other
CDNI Logging record-types that may be defined in separate
specifications. When a Field from this registry is used by another
CDNI Logging record-type, it is to be used with the exact semantics
and format specified in the document that registered this field and
that is identified in the Reference column of the registry. If
another CDNI Logging record-type requires a Field with semantics that
are not strictly identical, or a format that is not strictly
identical then this new Field is to be registered in the registry
with a different Field name. When a Field from this registry is used
by another CDNI Logging record-type, it can be used with different
occurrence rules.
The initial contents of the CDNI Logging fields Names registry
comprise the names of the CDNI Logging fields specified in
Section 3.4 of the present document, and are as follows:
Le Faucheur, et al. Expires November 26, 2016 [Page 50]
Internet-Draft CDNI Logging May 2016
+------------------------------------------+-----------+
| Field Name | Reference |
+------------------------------------------+-----------+
| date | RFC xxxx |
| time | RFC xxxx |
| time-taken | RFC xxxx |
| c-groupid | RFC xxxx |
| s-ip | RFC xxxx |
| s-hostname | RFC xxxx |
| s-port | RFC xxxx |
| cs-method | RFC xxxx |
| cs-uri | RFC xxxx |
| u-uri | RFC xxxx |
| protocol | RFC xxxx |
| sc-status | RFC xxxx |
| sc-total-bytes | RFC xxxx |
| sc-entity-bytes | RFC xxxx |
| cs(insert_HTTP_header_name_here) | RFC xxxx |
| sc(insert_HTTP_header_name_here) | RFC xxxx |
| s-ccid | RFC xxxx |
| s-sid | RFC xxxx |
| s-cached | RFC xxxx |
+------------------------------------------+-----------+
Figure 12
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document]
Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226]. Field
names are to be allocated by IANA with a format of NHTABSTRING (see
Section 3.1). All field names defined in the logging file are case-
insensitive as per the basic ABNF([RFC5234]).
6.5. CDNI Logging MIME Media Type
The IANA is requested to register the following new Payload Type in
the CDNI Payload Type registry for use with the application/cdni MIME
media type.
[RFC Editor Note: Please replace the references to [RFCthis] below
with this document's RFC number before publication.]
Le Faucheur, et al. Expires November 26, 2016 [Page 51]
Internet-Draft CDNI Logging May 2016
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| logging-file | [RFCthis] |
+----------------------+---------------+
Figure 13: MIME Media Type payload
The purpose of the logging-file payload type is to distinguish
between CDNI Logging Files and other CDNI messages.
Interface: LI
Encoding: see Section 3.2, Section 3.3 and Section 3.4
7. Security Considerations
7.1. Authentication, Authorization, Confidentiality, Integrity
Protection
An implementation of the CDNI Logging interface MUST support TLS
transport of the CDNI Logging feed (Section 4.1) and of the CDNI
Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230].
The use of TLS for transport of the CDNI Logging feed and CDNI
Logging File pull allows:
o the dCDN and uCDN to authenticate each other
and, once they have mutually authenticated each other, it allows:
o the dCDN and uCDN to authorize each other (to ensure they are
transmitting/receiving CDNI Logging File to/from an authorized
CDN)
o the CDNI Logging information to be transmitted with
confidentiality
o the integrity of the CDNI Logging information to be protected
during the exchange.
In an environment where any such protection is required, mutually
authenticated encrypted transport MUST be used to ensure
confidentiality of the logging information, and to do so, TLS MUST be
used (including authentication of the remote end) by the server-side
and the client-side of the CDNI Logging feed, as well as the server-
side and the client-side of the CDNI Logging File pull mechanism.
Le Faucheur, et al. Expires November 26, 2016 [Page 52]
Internet-Draft CDNI Logging May 2016
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
followed.
The SHA256-hash directive inside the CDNI Logging File provides
additional integrity protection, this time targeting potential
corruption of the CDNI logging information during the CDNI Logging
File generation, storage or exchange. This mechanism does not itself
allow restoration of the corrupted CDNI Logging information, but it
allows detection of such corruption and therefore triggering of
appropriate corrective actions (e.g., discard of corrupted
information, attempt to re-obtain the CDNI Logging information).
Note that the SHA256-hash does not protect against tampering by a
third party, since such a third party could have recomputed and
updated the SHA256-hash after tampering. Protection against third
party tampering when the CDNI Logging File is communicated over the
CDN Logging Interface can be achieved as discussed above through the
use of TLS.
7.2. Denial of Service
This document does not define specific mechanism to protect against
Denial of Service (DoS) attacks on the Logging Interface. However,
the CDNI Logging feed and CDNI Logging pull endpoints are typically
to be accessed only by a very small number of valid remote endpoints
and therefore can be easily protected against DoS attacks through the
usual conventional DOS protection mechanisms such as firewalling or
use of Virtual Private Networks (VPNs).
Protection of dCDN Surrogates against spoofed delivery requests is
outside the scope of the CDNI Logging interface.
7.3. Privacy
CDNs have the opportunity to collect detailed information about the
downloads performed by End Users. A dCDN is expected to collect such
information into CDNI Logging Files, which are then communicated to
an uCDN.
Having detailed CDNI logging information known by the dCDN in itself
does not represent a particular privacy concern since the dCDN is
obviously fully aware of all information logged since it generated
the information in the first place. Making detailed CDNI logging
information known to the uCDN does not represent a particular privacy
concern because the uCDN is already exposed at request redirection
time to most of the information that shows up as CDNI logging
information (e.g., enduser IP@, URL, HTTP headers - at least when
HTTP redirection is used between uCDN and dCDN). Transporting
detailed CDNI logging information over the HTTP based CDNI Logging
Le Faucheur, et al. Expires November 26, 2016 [Page 53]
Internet-Draft CDNI Logging May 2016
Interface does not represent a particular privacy concern because it
is protected by usual IETF privacy-protection mechanism (e.g.,TLS).
However, one privacy concern arises from the fact that large volumes
of detailed information about content delivery to users, potentially
traceable back to indvidual users, may be collected in CDNI Logging
files. These CDNI Logging files represent high-value targets, likely
concentrated in a fairly centralised system (although the CDNI
Logging architecture does not mandate a particular level of
centralisation/distribution) and at risk of potential data
exfiltration. Note that the means of such data exfiltration are
beyond the scope of the CDNI Logging interface itself (e.g.,
corrupted employee, corrupted logging storage system,...). This
privacy concern calls for some protection.
The collection of large volumes of such information into CDNI Logging
Files introduces potential End Users privacy protection concerns.
Mechanisms to address these concerns are discussed in the definition
of the c-groupid field specified in Section 3.4.1.
The use of mutually authenticated TLS to establish a secure session
for the transport of the CDNI Logging feed and CDNI Logging pull as
discussed in Section 7.1 provides confidentiality while the logging
information is in transit and prevents any party other than the
authorised uCDN to gain access to the logging information.
We also note that the query string portion of the URL that may be
conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or
the HTTP cookies( [RFC6265]) that may be conveyed as part of the
cs(<HTTP-header-name>) field of CDNI Logging files, may contain
personnal information or information that can be exploited to derive
personal information. Where this is a concern, the CDNI Logging
interface specification allows the dCDN to not include the cs-uri and
to include a u-uri that removes (or hides) the sensitive part of the
query string and allows the dCDN to not include the cs(<HTTP-header-
name>) fields corresponding to HTTP headers associated with cookies.
8. Acknowledgments
This document borrows from the W3C Extended Log Format [ELF].
Rob Murray significantly contributed into the text of Section 4.1.
The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and
Ray van Brandenburg for their ongoing input.
Brian Trammel and Rich Salz made significant contributions into
making this interface privacy-friendly.
Le Faucheur, et al. Expires November 26, 2016 [Page 54]
Internet-Draft CDNI Logging May 2016
Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian
Jacquenet, Yannick Le Louedec, Anne Marrec, Emile Stephan, Fabio
Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the
contributors of the EU FP7 OCEAN project for their input in the early
versions of this document.
9. References
9.1. Normative References
[AES] NIST, "Advanced Encryption Standard (AES)", August 2015,
<FIPS 197>.
[GCM] NIST, "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", November 2007, <SP
800-38D>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>.
Le Faucheur, et al. Expires November 26, 2016 [Page 55]
Internet-Draft CDNI Logging May 2016
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requestsquot; 96
bit address on a per PW Attachment Circuit basis. Only the T-PE
Global ID, Prefix, and prefix length needs to be advertised as part
of well known BGP procedures - see [RFC4760].
As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this
information to obtain the first S-PE hop (i.e., first BGP next hop)
to where the first PW segment will be established. Any subsequent S-
PEs will use the same information (i.e. the next BGP next-hop(s)) to
obtain the next-signaling-hop(s) on the path to the TT-PE.
The PW dynamic path NLRI is advertised in BGP UPDATE messages using
the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The [AFI,
SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6
(pending IANA allocation)). A route target MAY also be advertised
along with the NLRI.
Martini, et al. [Page 9]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
The Next Hop field of MP_REACH_NLRI attribute SHALL be interpreted as
an IPv4 address, whenever the length of the NextHop address is 4
octets, and as a IPv6 address, whenever the length of the NextHop
address is 16 octets.
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
comprising an 8-octet Route Distinguisher, the Global ID, the Prefix,
and the AC-ID, and encoded as defined in section 4 of [RFC4760].
This NLRI is structured as follows:
Bit
0 7 8 71 72 103 104 135 136 167
+------+----------------+-----------+--------+--------+
|Length| Route Dist | Global ID | Prefix | AC ID |
+------+----------------+-----------+--------+--------+
The Length field is the prefix length of the Route Distinguisher +
Global ID + Prefix + AC-ID in bits.
Except for the default PW route, which is encoded as a 0 length
prefix, the minimum value of the length field is 96 bits. Lengths of
128 bits to 159 bits are invalid as the AC ID field cannot be
aggregated. The maximum value of the Length field is 160 bits. BGP
advertisements received with invalid prefix lengths MUST be rejected
as having a bad packet format.
6.2. LDP Signaling
The LDP signaling procedures are described in [RFC4447] and expanded
in [RFC6073]. No new LDP Signaling components are required for
setting up a dynamically placed MS-PW. However some optional
signaling extensions are described below.
6.2.1. MS-PW Bandwidth Signaling
In order to enable the QoS objectives for a PW to be met on a
segment, a PSN tunnel MUST be selected that can support at least the
required class of service and that has sufficient bandwidth
available.
Martini, et al. [Page 10]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
PW QoS objectives can thus be met where the next hop for a PW segment
is explicitly configured at each PE, whether the PE is a T-PE or an
S-PE in the case of a segmented PW without dynamic path selection (as
per RFC6073). In these cases, it is possible to explicitly configure
the bandwidth required for a PW so that the T-PE or S-PE can reserve
that bandwidth on the PSN tunnel.
Where dynamic path selection is used and therefore the next-hop is
not explicitly configured by the operator at the S-PE, a mechanism is
required to signal the bandwidth for the PW from the T-PE to the S-
PEs. This is accomplished by including an OPTIONAL PW Bandwidth TLV.
The PW Bandwidth TLV is specified as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW BW TLV (0x096E) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The complete definitions of the content of the SENDER_TSPEC objects
are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to
the data path in the direction of ST-PE to TT-PE. The reverse
SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE.
In the forward direction, after a next hop selection is determined, a
T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine
an appropriate PSN tunnel towards the next signaling hop. If such a
tunnel exists, the MS-PW signaling procedures are invoked with the
inclusion of the PW Bandwidth TLV. When the PE searches for a PSN
tunnel, any tunnel which points to a next hop equivalent to the next
hop selected will be included in the search.(The LDP address TLV is
used to determine the next hop equivalence)
When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is
selected, the S/T-PE MUST request the appropriate resources from the
PSN. The resources described in the reverse SENDER_TSPEC are
allocated from the PSN toward the originator of the message or
previous hop. When resources are allocated from the PSN for a
specific PW, then the PSN SHOULD account for the PW usage of the
resources.
In the case where PSN resources towards the previous hop are not
available the following procedure MUST be followed:
Martini, et al. [Page 11]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
-i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to
the PSN tunnel.
-ii. The S-PE MAY attempt to setup another PSN tunnel to
accommodate the new PW QoS requirements.
-iii. If the S-PE cannot get enough resources to setup the segment
in the MS-PW a label release MUST be returned to the
previous hop with a status message of "Bandwidth resources
unavailable"
In the latter case, the T-PE receiving the status message MUST also
withdraw the corresponding PW label mapping for the opposite
direction if it has already been successfully setup.
If an ST-PE receives a label mapping message the following procedure
MUST be followed:
If the ST-PE has already sent a label mapping message for this PW
then the ST-PE MUST check that this label mapping message originated
from the same LDP peer to which the corresponding label mapping
message for this particular PW was sent. If it is the same peer, the
PW is established. If it is a different peer, then ST-PE MUST send a
label release message, with a status code of "Duplicate AII" to the
PE that originate the LDP label mapping message.
If the PE has not yet sent a label mapping message for this
particular PW , then it MUST send the label mapping message to this
same LDP peer, regardless of what the PW TAII routing lookup result
is.
6.2.2. Equal Cost Multi Path (ECMP) in PW Routing
A specific PW may find match with a PW route that may have multiple
next-hops associated with it. Multiple next-hops may be either
configured explicitly as static routes or may be learned through BGP
routing procedures. Implementations at and S-PE or T-PE MAY use
selection algorithms, such as CRC32 on the FEC TLV, for load
balancing of PWs across multiple next-hops. The details of such
selection algorithms are outside the scope of this document.
6.2.3. Active/Passive T-PE Election Procedure
When a MS-PW is signaled, each T-PE might independently initiate
signaling the MS-PW. This could result in a different path being used
be each direction of the PW. To avoid this situation one of the T-PE
MUST start the PW signaling (active role), while the other T-PE waits
to receive the LDP label mapping message before sending the LDP label
Martini, et al. [Page 12]
Internet Draft draft-ietf-pwe3-dynamic-ms-pw-17.txt June 19, 2013
mapping message for the reverse direction of the PW (passive role).
The Active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be
identified before signaling begins for a given MS-PW.
The determination of which T-PE assume the active role SHOULD be done
as follows: the SAII and TAII are compared as unsigned integers, if
the SAII is bigger then the T-PE assumes the active role.
6.2.4. Detailed Signaling Procedures
On receiving a label mapping message, the S-PE MUST inspect the FEC
TLV. If the receiving node has no local AII matching the TAII for
that label mapping then the finagling should be forwarded on to
another S-PE or T-PE. The S-PE will check if the FEC is already
installed for the forward direction:
- If it is already installed, and the received mapping was received
from the same LDP peer where the forward LDP label mapping was
sent, then this label mapping represents signaling in the reverse
direction for this MS-PW segment.
- If it is already installed, and the received mapping was received
from a different LDP peer where the forward LDP label mapping was
sent, then the received label mapping MUST be released with
status code as "PW_LOOP_DETECTED". If the already installed PW
segment has not signaled explicit intent for active role then
installed PW segment MUST be released with status code
"PW_LOOP_DETECTED".
- If the FEC is not already installed, then this represents
signaling in the forward direction.
For the forward direction:
-i. Determine the next hop S-PE or T-PE according to the
procedures above. If next-hop reachability is not found in
the PW AII routing table in the S-PE then label release MUST
be sent with status code "AII_UNREACHABLE". If the next-hop
S-PE or T-PE is found and is the same LDP Peer that has sent
the label mapping message then a label Release MUST be
returned with the status code "PW_LOOP_DETECTED". If the
SAII in the received label mapping is local to the S-PE then
a label released MUST be returned with status code
"PW_LOOP_DETECTED&",
RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
Le Faucheur, et al. Expires November 26, 2016 [Page 56]
Internet-Draft CDNI Logging May 2016
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[SHA-3] NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND
EXTENDABLE OUTPUT FUNCTIONS", November 2001,
<http://dx.doi.org/10.6028/NIST.FIPS.202>.
9.2. Informative References
[CHAR_SET]
"IANA Character Sets registry",
<http://www.iana.org/assignments/character-sets/
character-sets.xml>.
[ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended
Log File Format, W3C (work in progress), WD-logfile-
960323", <http://www.w3.org/TR/WD-logfile.html>.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-17 (work in progress), May 2016.
[I-D.ietf-tls-rfc5246-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00
(work in progress), April 2014.
[I-D.snell-atompub-link-extensions]
Snell, J., "Atom Link Extensions", draft-snell-atompub-
link-extensions-09 (work in progress), June 2012.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<http://www.rfc-editor.org/info/rfc1945>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
Le Faucheur, et al. Expires November 26, 2016 [Page 57]
Internet-Draft CDNI Logging May 2016
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013,
<http://www.rfc-editor.org/info/rfc6983>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
December 2015, <http://www.rfc-editor.org/info/rfc7736>.
Authors' Addresses
Francois Le Faucheur (editor)
Phone: +33 6 19 98 50 90
Email: flefauch@gmail.com
Le Faucheur, et al. Expires November 26, 2016 [Page 58]
Internet-Draft CDNI Logging May 2016
Gilles Bertrand (editor)
Orange
38-40 rue du General Leclerc
Issy les Moulineaux 92130
FR
Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com
Iuniana Oprescu (editor)
FR
Email: iuniana.oprescu@gmail.com
Roy Peterkofsky
Google Inc.
345 Spear St, 4th Floor
San Francisco CA 94105
USA
Email: peterkofsky@google.com
Le Faucheur, et al. Expires November 26, 2016 [Page 59]