Internet DRAFT - draft-bryden-personal-content-tunnels
draft-bryden-personal-content-tunnels
Network Working Group S.D. Bryden
Internet-Draft Nortel Networks
Expires: February 11, 2002 August 13, 2001
Personal Content Tunnels
draft-bryden-personal-content-tunnels-01.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 February 11, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
As broadband access networks begin to mature, applications such as
video-on-demand, application hosting and gaming are becoming viable
service offerings. In order to provide these types of service, it is
necessary to have extremely granular bandwidth control to ensure
that user session traffic has a highly predictable traffic delivery
profile.
The Personal Content Tunnel framework provides this control in a
session-oriented subscriber-driven manner allowing the most
efficient use of access network bandwidth.
Bryden Expires February 11, 2002 [Page 1]
Internet-Draft Personal Content Tunnels August 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Conformance requirement terminology . . . . . . . . . . . . 3
2.2 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. PCT Framework . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 PCT in Access Concentrator . . . . . . . . . . . . . . . . . 5
3.2 PCT in browser walkthrough . . . . . . . . . . . . . . . . . 5
3.3 PCT Object . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Request Authentication . . . . . . . . . . . . . . . . . . . 7
4. PCT Resolution Protocol . . . . . . . . . . . . . . . . . . 8
4.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 8
4.2 Request Format . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Request Headers . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2 Accept-Protocol . . . . . . . . . . . . . . . . . . . . . . 9
4.3.3 Client-Id . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.4 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Response Format . . . . . . . . . . . . . . . . . . . . . . 10
4.5 Response Headers . . . . . . . . . . . . . . . . . . . . . . 10
4.5.1 Location . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.2 Use-Protocol . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.3 Tunnel-Endpoint . . . . . . . . . . . . . . . . . . . . . . 11
4.5.4 Tunnel-Path . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.5 Username . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.6 Password . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.7 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.8 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4 Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IP as a null transport technology . . . . . . . . . . . . . 14
7. Tunnel Tear-down . . . . . . . . . . . . . . . . . . . . . . 14
8. Practical Considerations . . . . . . . . . . . . . . . . . . 14
8.1 Streaming Media Support . . . . . . . . . . . . . . . . . . 15
8.2 Other Applications . . . . . . . . . . . . . . . . . . . . . 15
9. Security considerations . . . . . . . . . . . . . . . . . . 15
10. Further Study . . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Bryden Expires February 11, 2002 [Page 2]
Internet-Draft Personal Content Tunnels August 2001
1. Introduction
Content delivery performance can broadly be improved in two ways: by
adding more bandwidth, or by moving the content closer to the edge.
The latter allows a reduction in the bandwidth required to deliver
the content, however it brings many problems, such as maintenance,
management and administration of the content distribution process
and of the content caching hardware. Adding bandwidth is
traditionally the more expensive solution, but as bandwidth costs
continue to decrease, the problem becomes one of finding a balance
between the number and location of the surrogates and the
distribution and control of the bandwidth. PCT allows Access
Providers and Network Infrastructure Providers to engineer this
level of control into their networks, by enabling session-driven
traffic paths to be established to the most suitable surrogate.
The Personal Content Tunnel mechanism provides a content driven
session initiation mechanism. PCTs are intended for use by
subscriber access gateways or client browsers to establish
individual, "focused" content delivery channels. Such channels may
be used to deliver content requiring custom traffic parameters, such
as high bandwidth, low latency, or a preferred forwarding path.
Dynamically created sessions would establish such traffic
parameters, and remain active for the duration needed by the
delivered content.
By allocating just enough bandwidth through this path, and by
holding the allocation only for the duration of the session, the use
of the available bandwidth is optimised. At the same time, the
session is guaranteed to have sufficient bandwidth for the duration
of the content download.
2. Terminology
2.1 Conformance requirement terminology
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 RFC2119[1]
2.2 Glossary of Terms
Subscriber: The end-user who is subscribed to a broadband access
provider and who is the consumer of the content.
Tunnel: An encapsulation of subscriber traffic which allows network
components to apply some kind of QoS to a subscriber session. The
use of MPLS is recommended since it provides a very rich set of
QoS and traffic engineering functionality, but other protocols
Bryden Expires February 11, 2002 [Page 3]
Internet-Draft Personal Content Tunnels August 2001
such as L2TP can be used to give lower functionality where MPLS
is not available.
PCT Resolution Server: The server which accepts requests from PCT
clients requesting information on how to access a certain item of
content, and returns the location of a suitable surrogate along
with details of how to build a tunnel in order to guarantee the
QoS required to view the content.
PCT Client: The device which initiates the PCT process, makes the
request to the resolution server, and ultimately requests the
bandwidth on behalf of the subscriber. This can either be an
intelligent edge device through which the subscriber receives his
service, or can be a plugin inside of the subscriber's browser.
PCT Object: An information structure containing "static" information
about an item of content, such as the bandwidth required for
viewing or the location of the PCT resolution server.
Service URI: A URI (universal resource identifier) which describes
both the address of the PCT resolution server and the identity of
the content requested by the subscriber. This information is
contained in the PCT object.
Content URI: This URI represents the location of the content copy on
the chosen surrogate. It is the main output of the PCT resolution
server.
Access Concentrator: This is a device close to the subscriber, such
as a broadband RAS (BRAS), a DSL access multiplexer (DSLAM), or a
cable modem termination system (CMTS). It is not necessarily
directly connected to the subscriber but since the PCT client is
intended to be located in such a device, ideally it should be as
close as possible.
PCT Resolution Protocol: The protocol used for the communication
between the PCT client and the PCT resolution server. For a given
subscriber and content item, it determines the locatio of the
most suitable surrogate and a suitable mechanism for assuring the
QoS between the client and the surrogate.
3. PCT Framework
PCT can operate in two basic modes. In the first, the PCT client is
implemented in an access concentrator and provides a service which
is transparent to the subscriber. In the second, in order to allow
operation in environments where the appropriate PCT support is not
available in access concentrators or other intelligent edge devices,
provision is made for the PCT client functionality to be implemented
Bryden Expires February 11, 2002 [Page 4]
Internet-Draft Personal Content Tunnels August 2001
in a browser plug-in on the subscriber's PC.
3.1 PCT in Access Concentrator
When the PCT client is implemented in an access concentrator, a
typical session proceeds as follows:
1. A subscriber browses to a content website or to a portal and
selects a link
2. An intelligent access concentrator (AC), intelligent IP-enabled
DSLAM or any other access server such as a CMTS or RAS matches
the request to a preconfigured filter and reads a PCT object
from its local configuration, or from a directory service such
as an LDAP directory. This object contains static information
about the content (ie information which is constant regardless
of the location or identity of the subscriber) as well as the
location of the PCT resolution server.
3. The PCT object is parsed by the AC and a PCT resolution request
is sent to a PCT resolution server.
4. The PCT resolution server sends a response indicating the
location of the most suitable surrogate containing the requested
content, along with the information required to build a tunnel
or traffic-engineered path to a device close to the surrogate.
5. The AC establishes the tunnel, then sends an HTTP redirect
message back to the subscriber causing the the browser to
restart the session to the surrogate. At the same time, the AC
installs some local policy configuration which causes all data
corresponding to this session to be forwarded along the tunnel
6. When the AC detects the end of the session, the tunnel is torn
down and the local policy configuration is removed.
3.2 PCT in browser walkthrough
In this case, the plug-in is linked via the browser configuration to
the well-known (TBD) mime type of the PCT object. When a subscriber
clicks on a PCT object (which would typically be embedded in html
and located on a portal at the Access Provider's site) the plug-in
is automatically launched and its operation is as follows:
1. The PCT object is parsed by the plug-in and a PCT resolution
request is sent to a PCT resolution server.
2. The PCT resolution server sends a response indicating the
location of the most suitable surrogate containing the requested
Bryden Expires February 11, 2002 [Page 5]
Internet-Draft Personal Content Tunnels August 2001
content, along with the information required to build a tunnel
or traffic-engineered path to a device close to the surrogate.
3. The plug-in establishes the tunnel and installs a route in the
client PC to the content location IP address and the subnet mask
supplied in the PCT object. This causes all data corresponding
to this session to be forwarded along the tunnel.
4. The plug-in now sends a redirect message to the browser
requesting it to redirect its original request to the content
surrogate as supplied by the PCT resolution response. The data
is fed into the tunnel automatically due to the route which was
installed by the plug-in.
5. Now that the content download has started, the plug-in monitors
the traffic flow in order to determine when the tunnel should be
torn down and the routing entry removed. This can be a complex
flow-following process, or a simple timeout, in which case a
session timeout or an idle timeout can be specified in the PCT
object.
6. When any of the above events occurs, the plug-in tears down the
tunnel, removes the routing entry from the table and then exits.
When the tunnel is initiated from a client PC, it is expected that
the tunnel type will be PPTP or L2TP, or even PPPoE. Since none of
these tunnel technologies are particularly suited to bandwidth
control, a more practical technique could be tunnel switching, where
the incoming traffic to a network edge device is switched onto a
shared MPLS path or other guaranteed bandwidth path based on the
authentication attributes supplied at tunnel setup time. In this
case, the level of bandwidth guarantee is less granular, but by
provisioning a path with sufficient bandwidth and analysing the mean
traffic requirement, a workable solution can be achieved.
3.3 PCT Object
The static information about the content is contained in a PCT
Object. This can be either an object contained on a website as e.g.
an XML object, or can be held in the local configuraion of an access
concentrator in a proprietary format. Either way, it is retrieved at
the time the content is requested and the information contained
within is used to determine the location of the PCT resolution
server and other information. Typical contents of the object would
be as follows:
Service URI: The URI of the PCT resolution server. This provides
two distinct pieces of information. Firstly, the host part of
the URI specifies the location of the PCT resolution server,
Bryden Expires February 11, 2002 [Page 6]
Internet-Draft Personal Content Tunnels August 2001
and secondly the path part tells the resolution server which
actual object was being requested by the subscriber. The PCT
resolution server uses this information to construct the final
content URI which specifies the location of the content on the
surrogate server.
Static Routing Control: A subnet mask to be applied to the
routing entry as installed by a client PC when using a browser
plugin. In this case, the session traffic is identified in the
client PC as matching the Content URI address with this subnet
mask.
Session Timeout: The absolute timeout after which a tunnel should
be torn down and the associated policy removed and resources
released.
Idle Timeout: The idle timeout after which, if no data has passed
in either direction, the tunnel should be torn down and the
associated policy removed and resources released.
Bandwidth Parameters: The bandwidth profile required for this
content. The required bandwidth is determined from the
encoding of the content and can usually be automatically
extracted from the original content metafile. This information
can be used to determine whether a subscriber has sufficient
bandwidth to view the content before making the resolution
request. The case where multiple encodings exist of the same
content can be handled either by having a PCT object per
encoding, or by having one PCT object describing the lowest
bandwidth requirement, then specifying the actual bandwidth
available in the resolution request. This is described in
Section 4.3.4.
3.4 Request Authentication
When operating in the browser mode, care must be taken to prevent
subscribers from bypassing the initial request and initiating a
tunnel directly, potentially bypassing billing procedures or taking
non-optimal paths.
This can be avoided by returning username and password attributes
which are autogenerated and useful only for the current session.
This may be a one-time-only authentication, or it could be
time-limited, or could be linked to client IP address, however
whichever method is chosen, these values are opaque to PCT and will
be interpreted by the tunnel server at tunnel setup time.
The domain attribute can also be used to add a further level of
control to the authentication process. If returned, the domain
Bryden Expires February 11, 2002 [Page 7]
Internet-Draft Personal Content Tunnels August 2001
string will be appended to the username string with the separator
'@'.
The format of the username, password and domain values will be
determined by the tunnelling protocols used (eg L2TP, PPTP, PPPoE).
For details, refer to the appropriate specifications.
4. PCT Resolution Protocol
4.1 Protocol Overview
The PCT resolution protocol is used for communication between a PCT
client and a PCT resolution server. A transaction consists of one
request and one response. The client request identifies the
subscriber and the requested content. It also contains some "hints"
about the bandwidth available to the subscriber and the bandwidth
reservation/tunnelling protocols which can be supported by the
client. The response provides the location of the most suitable
surrogate as well as information required to build a tunnel or
bandwidth reservation contract in order to provide the QoS required
for the content delivery.
PCT resolution protocol (PCTRP) is loosely based on HTTP [3].
Communication takes place over TCP/IP connections using port TBD.
The connection is initiated by the PCTRP client and a single request
is sent. The server responds with a single response, and the
connection is closed.
4.2 Request Format
As in HTTP, PCTRP requests must start with a request line that
contains a method, the complete service URI and the PCTRP version
string. These three items are described here:
A new method is defined named RESOLVE. This method requests that a
service URI be resolved into a content URI
Service URIs have a format as described in [4]. The scheme used for
PCTRP messages is "pctrp".
The version of PCTRP defined in this document is version 1.0
An example of a complete request line would be:
RESOLVE pctrp://pctrs.movies.com/xyz.avi PCTRP/1.0
4.3 Request Headers
Following the start line, there are a list of headers, one per line,
Bryden Expires February 11, 2002 [Page 8]
Internet-Draft Personal Content Tunnels August 2001
which contain details of the resolution request. Each of these
headers MUST appear no more than once, and some are mandatory:
4.3.1 Host
PCTRP uses the Host header in the same way as HTTP/1.1, to identify
the host to which the request is being sent.
Status: REQUIRED
Example:
Host: pctrs.movies.com
4.3.2 Accept-Protocol
This header defines which tunnelling protocols are acceptable by the
client. Multiple protocols can be separated by commas.
Status: OPTIONAL
Example:
Accept-Protocol MPLS
Accept-Protocol PPTP, L2TP
4.3.3 Client-Id
This header contains information about the location of the client
and is used by the PCT resolution server to decide the best choice
of surrogate and path for the request. The value of this header will
typically be an IP address, but any printable string can be used.
Status: OPTIONAL
Example:
Client-Id: 192.168.48.30
Client-Id: WestCoastPop
Optionally the PCTRS can infer in a more accurate and
straightforward Geographic position of the client through the use of
the data provided by the User Profile Information Protocol [10].
4.3.4 Bandwidth
This header contains information about the bandwidth available to
the client. It is used by the PCT resolution server to decide on the
appropriate encoding of the content to be delivered in cases where
it is aware of multiple encodings of the same content. The format of
the value of this header is an ascii encoded numeric value
representing the available bandwidth in bits per second.
Bryden Expires February 11, 2002 [Page 9]
Internet-Draft Personal Content Tunnels August 2001
Status: OPTIONAL
Example:
Bandwidth: 1000000
Optionally the PCTRS can infer the layer 2 and layer 3 bandwidth
restrictions of the user in a more accurate way through the use of
the data provided by the User Profile Information Protocol [10].
If the PCTRS discovers that the user does not have enough downstream
or upstream bandwidth to view the requested object, it can use a
out-of-band signalling protocol to tell the AC to increase the
bandwidth of the user. Today several ACs already have this
capability.
4.4 Response Format
PCTRP responses must start with an PCTRP status line, similar in
form to that used by HTTP, including the PCTRP version and a status
code. For example:
PCTRP/1.0 200 OK
The supported status codes are:
200 OK, normal response
220 Able to satisfy request with bandwidth increase
400 Bad request. The request header was malformed
404 Unable to resolve this URI
4.5 Response Headers
Following the start line, there are a list of headers, one per line,
which contain details of the resolution response:
4.5.1 Location
This header indicates the address of the surrogate which has been
selected to serve the requested content.
Status: REQUIRED
Example:
Location: 192.168.12.34
Location: popWest.isp.com
4.5.2 Use-Protocol
This header indicates the tunnelling protocol to be used by the
Bryden Expires February 11, 2002 [Page 10]
Internet-Draft Personal Content Tunnels August 2001
client. It is usually (but not necessarily) one of those listed in
the Accept-Protocol request header.
Status: REQUIRED
Example:
Use-Protocol: MPLS
4.5.3 Tunnel-Endpoint
This header indicates the tunnel endpoint address to be used to
access the content.
Status: REQUIRED if the protocol referred to in the Use-Protocol
header requires a tunnel endpoint to be specified, otherwise it MUST
NOT be included.
Example:
Tunnel-Endpoint: 192.168.56.78
Tunnel-Endpoint: dataCentre1.isp.com
4.5.4 Tunnel-Path
This header indicates the explicitly-routed path to be used to set
up the tunnel.
Status: OPTIONAL
Example:
Tunnel-Path: 192.168.56.1, 192.168.23.4, 192.168.36.5
4.5.5 Username
This header represents the username which should be used when
setting up an authenticated tunnel. It is used in conjunction with
the Password and Domain attributes described below. If any of the
authentication attributes are not returned, they SHOULD be omitted
in the tunnel setup, however if the tunnel setup protocol requires
that a value be supplied, a dummy value MUST be inserted by the
client, which should be ignored by the tunnel authentication server.
Status: OPTIONAL
Example:
Username: AP185U364523
Password: OneTime5rd$3@#eF6$%hu75D5$3
Domain: goldservice
Bryden Expires February 11, 2002 [Page 11]
Internet-Draft Personal Content Tunnels August 2001
4.5.6 Password
This header represents the password which should be used when
setting up an authenticated tunnel
Status: OPTIONAL
4.5.7 Domain
This header represents the domain value which should be used when
setting up an authenticated tunnel. It should be combined with the
username in the form username@domain. In tunnel switching scenarios,
it can be used to select the outgoing tunnel, and thus act as a
traffic engineering attribute
Status: OPTIONAL
4.5.8 Bandwidth
This header indicates the bandwidth required to download the
requested content. This value may be different from the Bandwidth
parameter sent in the request since this parameter specifies what is
required for the content, whereas the request bandwidth specifies
how much bandwidth the user has available.
Status: OPTIONAL
Example:
Bandwidth: 750000
5. Examples
In the following examples, imagine that a content provider has a
central site at www.movies.com and has local content caches on the
East and West coasts identified by westCoast.movies.com and
eastCoast.movies.com.
The PCT resolution server could choose one of these local caches
based on the identity of the subscriber.
5.1 Example 1
In this example, the client has IP address 192.168.48.30 and is
requesting the use of MPLS. The client has 1Mbps of bandwidth
available.
RESOLVE pctrp://pctrs.movies.com/xyz.avi PCTRP/1.0
Host: pctrs.movies.com
Client-Id: 192.168.48.30
Bryden Expires February 11, 2002 [Page 12]
Internet-Draft Personal Content Tunnels August 2001
Accept-Protocol: MPLS
Bandwidth: 1000000
Assuming that the server can resolve the requested service URI, the
corresponding reply could be:
PCTRP/1.0 200 OK
Location: http://westCoast.movies.com/xyz.avi
Use-Protocol: MPLS
Tunnel-Endpoint: 192.168.50.6
Bandwidth: 348000
5.2 Example 2
In this example, the client indicates his preference for L2TP, but
indicates that it also supports PPTP
RESOLVE pctrp://pctrs.movies.com/xyz.avi PCTRP/1.0
Host: pctrs.movies.com
Client-Id: 192.168.48.30
Accept-Protocol: L2TP,PPTP
Bandwidth: 64000
The server responds with protocol L2TP and with a set of
authentication parameters to be used when setting up the tunnel.
Note that in this example, there is no bandwidth reservation so the
corresponding response headers are omitted.
PCTRP/1.0 200 OK
Location: http://westCoast.movies.com/xyz.avi
Use-Protocol: L2TP
Username: westCoast7253
Password: RESOIHVHRTRUY
Alternatively, the server may know that there is a copy of the
requested content close to the subscriber attachment point, and in
this case would indicate a simple redirect by returning the IP
tunnel protocol type.
PCTRP/1.0 200 OK
Location: http://westCoast.movies.com/xyz.avi
Use-Protocol: IP
5.3 Example 3
Here, the pctrp transaction is shown for a request which the server
could not satisfy with the bandwidth specified. The response
specifies the bandwidth required. This can be interpreted by the
access concentrator which can then (perhaps after a confirmation
Bryden Expires February 11, 2002 [Page 13]
Internet-Draft Personal Content Tunnels August 2001
from the subscriber) increase the available bandwidth before making
the bandwidth reservation.
RESOLVE pctrp://pctrs.movies.com/xyz.avi PCTRP/1.0
Host: pctrs.movies.com
Client-Id: 192.168.48.30
Accept-Protocol: MPLS
Bandwidth: 384000
PCTRP/1.0 220 INSUFFICIENT BANDWIDTH
Location: http://westCoast.movies.com/xyz.avi
Use-Protocol: MPLS
Tunnel-Endpoint: 192.168.50.6
Bandwidth: 1000000
5.4 Example 4
Here, the response is shown for a request for which the server was
not aware of any available content.
PCTRP/1.0 404 NOT FOUND
6. IP as a null transport technology
The PCT resolution server is responsible for deciding which tunnel
technology should be used to provide the necessary QoS for the
session. IP is supported as a "null transport technology" to deal
with situations where a traffic engineered path is not needed. This
would typically be the case when the chosen surrogate is in the same
location as the access concentrator which is handling the
subscriber's connection.
7. Tunnel Tear-down
The termination of the tunnel can be controlled as follows:
Normally, the PCT will be torn down when the access concentrator
detects the end of the session, which it does by following the state
of the session and detecting the end of the flow.
Alternatively, if a client browser plugin is providing the PCT
client function, a session timeout or an idle timeout can be passed
in the PCT Object. The PCT client will use this to tear down the
tunnel when the specified session timeout period has elapsed, or if
the idle period has expired without data being passed.
8. Practical Considerations
Bryden Expires February 11, 2002 [Page 14]
Internet-Draft Personal Content Tunnels August 2001
8.1 Streaming Media Support
Since one of the target markets for PCT is video-on-demand, support
for streaming protocols is essential. Streaming protocols typically
have a control protocol which establishes one or more transport
sessions based on the contents of a metafile. This metafile contains
information about the various streams which make up the entire
content presentation, including the locations of the data and the
corresponding transport protocol.
It is suggested that to effectively support streaming media, the PCT
tunnels SHOULD be triggered on the transport sessions, rather than
the control session, and that the transport sessions be considered
to be distinct independent paths with their own destinations and
bandwidth requirements.
8.2 Other Applications
Most of this document has talked about services such as video on
demand, where guaranteed bandwidth is essential to a quality
end-user experience. However other services such as gaming and
network-served applications are also well suited to PCT. For these
services, an absolute QoS guarantee may not be required, and so the
use of bandwidth reservation signalling protocols may not be needed.
In these cases, tunnels can be used to direct traffic along shared
trunks, which could be dedicated to certain classes of traffic.
These trunks could be pre-provisioned and PCT used to direct the
subscriber traffic to a surrogate on the appropriate trunk.
9. Security considerations
Whenever a protocol describes bandwidth reservations, care must be
taken to ensure that all such requests are legitimate, meaning that
requesters are authenticated or that they (if anonymous) are
billable. This document assumes that in cases where a bandwidth
reservation is being made, one of the above conditions has been
satisfied by the access concentrator, or other security element in
the access network.
10. Further Study
There are many unanswered questions in this draft, such as how the
MPLS path signalling should be achieved, whether bandwidth needs to
be reserved in both directions, how the resolution server should get
its information. Also it is assumed that the bandwidth is required
throughout the user session. In the case of a video download, what
happens when a subscriber hits "pause"? Should we continue to hold
the bandwidth? What about gaming applications where the bandwidth
requirements may be relatively low during play but high between
Bryden Expires February 11, 2002 [Page 15]
Internet-Draft Personal Content Tunnels August 2001
levels, as new data is downloaded. All of these questions are
subjects for further study.
11. Acknowledgements
The author would like to thank Gil Tene for initially describing the
Personal Content Tunnel concept.
Bryden Expires February 11, 2002 [Page 16]
Internet-Draft Personal Content Tunnels August 2001
References
[1] Bradner, S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Bradner, S, "The Internet Standards Process - Revision 3", RFC
2026, March 1997.
[3] Gettys, R, Mogul, J, Frystyk, J, Masinter, H, Leach, L,
Berners-Lee, P and T Berners-Lee, "Hypertext Transfer Protocol
- HTTP/1.1", RFC 2616, June 1999.
[4] Berners-Lee, T, Fielding, R, Irvine, U C and L Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax", RFC
2396, August 1998.
[5] Rosen, B, Viswanathan, A and R Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[6] Awduche, D, Berger, L, Gan, D, Li, T, Swallow, G and V
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
[7] Jamoussi et al, B, "Constraint-Based LSP Setup using LDP",
draft-ietf-mpls-cr-ldp-05.txt, February 2001.
[8] Townsley, W, Valencia, A, Rubens, A, Pall, G, Zorn, G and B
Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[9] Makamos, L, Lidl, K, Evarts, J, Carrel, D, Simone, D and R
Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.
[10] Penno, R and A Albuquerque, "User Profile Information
Protocol", draft-penno-cdnp-nacct-userid-04.txt, July 2001.
Author's Address
Simon Bryden
Nortel Networks
25 Allee Pierre Ziller
Valbonne 06560
France
Phone: +33 4 9296 1565
EMail: sbryden@nortelnetworks.com
Bryden Expires February 11, 2002 [Page 17]
Internet-Draft Personal Content Tunnels August 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Bryden Expires February 11, 2002 [Page 18]
