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]