Network Working Group Jeremy De Clercq INTERNET DRAFT Sven Van den Bosch Alban Couturier Alcatel June 2003 Expires December, 2003 An architecture for a gradual deployment of end-to-end QoS on an Internet-wide scale (Virtual Service-aware Networks) 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document introduces Virtual Service-aware Networks (VSNs) as a solution for inter-domain resource reservation with Quality-of- Service (QoS) on an Internet-wide scale. A VSN is a single-domain overlay network that consists of guaranteed QoS pipes. VSNs of neighboring domains that offer the same level of QoS establish peering relationships. As such, they form a network of QoS-enabled networks with a specific (QoS) routing context. In this network, admission control for traffic flows is performed in two phases. The De Clercq et al. Expires December 2003 [Page 1] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 two-phase approach allows for the use of an off-path signaling protocol, which enables the gradual introduction of this architecture without changing the existing routers. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 1.1 QoS resource management....................................3 1.2 Scalability................................................3 1.3 Inter-domain aspects.......................................4 1.4 Deployment.................................................4 2. Terminology....................................................5 3. VSN concepts...................................................5 3.1 Two-level admission control................................6 3.2 Concatenation of QoS pipes.................................8 3.3 Data/control plane separation.............................10 4. VSN in a single-domain core network...........................12 4.1 Provisioning of QoS pipes.................................12 4.2 Per-flow admission-control................................12 4.3 Route Alignment...........................................13 5. VSN in a multiple-domain core network.........................14 5.1 BGP/MPLS VPN application..................................14 5.1.1 Creation of arbitrary overlay topologies..............15 5.1.2 VPN peering at border routers.........................15 5.1.3 End-to-end packet flow................................17 5.2 IP QoS application........................................18 5.3 Dynamic data/control plane alignment......................19 6. The QoS signaling protocol....................................20 7. Gradual VSN deployment........................................20 8. VSN assurance.................................................21 8.1 Performance monitoring....................................21 8.2 Resilience................................................22 9. Security and AAA Considerations...............................24 9.1 Trust issues..............................................24 9.2 Authentication, Authorization and Accounting..............25 9.3 Protocol security.........................................25 References.......................................................26 Acknowledgments..................................................27 Author's Addresses...............................................27 Full Copyright Statement.........................................27 1. Introduction De Clercq et al. Expires December 2003 [Page 2] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 In 2000, a collaborative effort on the part of Internet Architecture Board resulted in the specification of RFC 2990 [RFC2990], identifying next steps for the IP QoS architecture. RFC 2990 was an effort to identify essential precursors to widespread deployment and use of QoS-aware networks, in order to identify missing sections and additional refinements to the existing QoS model. The existing QoS models at the time, Integrated Services [RFC1633] and Differentiated Services [RFC2475], form two extremes of a continuum of control models where the fine-grained precision of per-flow reservation can be aggregated into larger more approximate reservation states and the element-by-element reservation can be progressively approximated by treating a collection of sub-networks or an entire transit network as an aggregate service element. The architectural direction that was pointed to was the adoption of an approach combining the per-flow service elements at the edge and aggregated service elements in the core. Examples of such an approach are RSVP aggregation [3175] and IntServ-over-DiffServ [2998]. The development of an end-to-end signaling protocol was seen as an essential step towards the combination of both types of architectures into an end-to-end model. Currently, work is ongoing in the Next Steps In Signaling (NSIS) working group to define such a protocol. RFC 2990 further identifies a number of challenges that a potential QoS architecture would need to address in order to be successful. They can essentially be categorized as related to either QoS resource management, scalability, inter-domain aspects or deployment. 1.1 QoS resource management It is clear that any proposal for a wide-scale QoS architecture cannot assume homogeneity of deployed QoS technology. As such, it needs to be prepared to reuse existing QoS resource management techniques. Additionally, it needs to be able to inter-work between networks where different resource management techniques are used. The VSN architecture strongly decouples resource management from resource reservation by means of the overlay topology concept explained in section 3.1. 1.2 Scalability IntServ, IntServ-over-DiffServ and RSVP aggregation use packet classifiers as an intrinsic part of their architecture. Fine-grained classifiers isolate traffic from a micro-flow and may cause the need to keep per-flow state where they are applied. With IntServ, this would be in every network element on the data path. With IntServ- over-DiffServ and RSVP aggregation, it would be at the edge of each domain. The admission control principle of the VSN approach described in this document (section 3.1) only requires per-flow state to be De Clercq et al. Expires December 2003 [Page 3] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 kept at the origin and the end-point of a reservation, irrespective of the number of domains in between the origin and end-point. 1.3 Inter-domain aspects The assumption within both the IntServ and the DiffServ architecture is that the Best-Effort routing path can be used for any service, whether this path is able to sustain the required service load or not. RFC 2990 points out that at least during the initial stages of QoS roll-out, this may not be the case. As such, it identifies the need for QoS routing and discovery of the service capabilities of a path. In the VSN architecture, this is supported by the separation of routing contexts for different deployed services. This allows for a per-service concatenation of QoS segments as explained in section 3.2. 1.4 Deployment Several issues are related to the architectural support of a certain service set and service deployment. One attempt to deploy QoS was made with the Qbone Premium Service [Qbone]. The effort was stopped because of what was seen as largely non-technical obstacles to deployment [Teitelbaum]: poor incremental deployment, intimidating new complexity, missing functionality on routers and serious economic challenges. Poor incremental deployment resulted from the tight coupling between data and control plane. This is exemplified by the need to upgrade all edge routers and by the decision to give DSCP values local significance only. Incremental deployment is considerably easier with the data-control plane separation principle proposed in section 3.3. The proposed architecture is built on a combination of techniques that are widely accepted and along the process of being deployed. More specifically, it can build on available VPN expertise and deployment which strongly reduces new complexity and the risk of non-compliant routers. It also addresses some of the business logic behind the proposition. For a network provider, deploying a VSN has no more impact than accepting a new VPN customer. Some issues raised in [RFC2990] and [Qbone] indeed require careful attention. The signaling protocol (section 6) is an essential part of the solution. VSN assurance (section 8) and security (section 9) will be crucial to the success of the proposed architecture. The VSN architecture is seen as an alternative implementation of the De Clercq et al. Expires December 2003 [Page 4] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 trade-off between aggregation and per-flow awareness. It additionally has better support for incremental deployment and supports more flexible business models than other proposals, both of which are seen as crucial aspects for the success of a QoS architecture. 2. Terminology AC: Admission Control. AP: Application Provider. The AP is a legal entity who uses a QoS- aware network to offer applications to end-users. BE: Best Effort. BR: Border Router. CE: Customer Edge device. Flow (or traffic flow): A traffic flow is a stream of packets between two end-points that can be isolated based on a packet classifier containing e.g. source address, destination address, DSCP, ... NAD: Network Access Device. An NAD is a device belonging to a AP that is connected to a NP's backbone network via a NP's PE. NP: Network Provider. The NP is the legal entity who owns and operates the backbone network and its network elements (PE and P) NSIS: Next Steps In Signaling Working Group. PE: Provider Edge router. A PE is a router that belongs to the NP and whereto access devices belonging to other entities (AP, customer) are attached. QC: QoS Controller. QI: QoS Initiator. QoS: Quality of Service. QoS packet: an IP packet that belongs to an IP flow that has been granted certain QoS guarantees. QoS pipe: a virtual link between two edges of a backbone network that has bandwidth and QoS guarantees associated with it. QP: QoS Service Provider. The QP is a legal entity who leases an overlay network with QoS guarantees from a Network Provider. The QP's customers are Application Providers who use the QP's QoS-aware network. QR: QoS Receiver. SLS: Service Level Specification. The SLS as used in this document is the specification of the QoS guarantees that are associated with a set of QoS pipes. VSN: Virtual Service-aware Network. VSN is the abbreviation used for the approach described in this document: a Network that allows to provide (end-to-end guaranteed) Services, using a Virtual overlay topology. 3. VSN concepts The architecture described in this specification relies on 3 basic concepts that will be described in the following subsections. De Clercq et al. Expires December 2003 [Page 5] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 3.1 Two-level admission control The first concept upon which this architecture is built, is a so- called ''two-level admission control.'' It is clear, that performing end-to-end hop-by-hop resource reservation in every node for every new (micro-)flow request is not scalable in large scale multi-domain networks. Backbone transit networks cannot keep per (micro-)flow state and do per (micro-)flow policing in their network elements. As such, this architecture proposes to distinguish two phases that need to occur prior to forwarding packets into the network. ****** : ****** : ****** *AP-1* : _ _ _ _ _ _ _ _ _ _ _* QP *_ _ _ : *AP-2* ****** : | ****** | : ****** : | + | : ...... : | ...... + | : ...... . QI .-:----|------------>. QC .-----+-------|----:->. QR . ...... : | ...... SLS | : ...... : __|_ + _|__ : : | |----------------------+-----| | : : | | QoS pipe + | | : : |____|----------------------+-----|____| : : | + | : : |_ _ _ _ _ _ _ _ _ _ _ _ + _ _ _ | : : + : .. .. :.. .. .. .. .. .. .. .. .. ..+ .. .. .. ..: .. .. . : + : : ****** : : _ _ _ _ _ _ _ _ _ _ _* NP * _ _ _ : : | ****** | : : | ___ | : : __|_ ___| | __|_ : ___ : | | / | P | ___ | | : ___ |NAD|--:-| PE |___/ ---\ | |________| PE |-:--|NAD| --- : |____| \_| P | |____| : --- : | --- | : : | | : : |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| : Figure 1: AP, QP, NP and SLS between QP and NP. In a first phase, ''QoS pipes'' are being provisioned between the edge devices of the considered single network. The characteristics of these QoS pipes are detailed in a Service Level Specification (SLS). By provisioning QoS pipes between ingress-egress pairs within a De Clercq et al. Expires December 2003 [Page 6] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 network, a virtual topology or ''overlay network'' is created. The owner of the underlying network (the Network Provider, NP) can lease such an overlay network to other entities that we will call QoS Providers (QP). Note that these two entities will have a different view on the network: the NP has a view of the complete network, with all its individual network elements. The QP only has a view on the overlay network of QoS pipes that it leases from the NP. The considered SLS will then for example specify the amount of bandwidth that is reserved for every QoS pipe of the overlay network. Note that the distinction between NP and QP can be purely logical (when the same legal entity plays both roles) or also effective (when two different legal entities play the different roles). The provisioning of a new QoS pipe takes into account any other existing resource reservations in the network: a new QoS pipe will only be allowed if there are enough unreserved resources available. This is the first phase of the ''two-level admission control''. The second phase is the actual admission or rejection of individual flows. It is assumed that every individual flow is being served by a QP, and as such will consume resources from that QP's logical topology of QoS pipes. The QP has a view on the pre-provisioned QoS pipes and on the resources consumed by existing flows. For every incoming flow request, the responsible QP needs to determine the QoS pipe that will be affected, and compare the available resources of that QoS pipe with the requirements of the new request. If the QoS pipe has enough resources available, the flow will be accepted, in the other case, it will be denied. This is the second phase in the two-level admission control procedure. Note that the NP doesn't need to be aware of these individual flows, it has only an aggregate view of the traffic. This functional separation also has an impact on the necessary traffic conditioning, which is also split in two phases. The first phase of admission control results in a traffic conditioning action on the QoS pipe by the NP. This traffic conditioning is performed at the NP's border routers at the edges of its network. By doing so, the NP makes sure that the QoS pipes behave as specified within the SLS's and as such the NP maintains an accurate view on the available resources in its backbone network. The second phase of admission control results in a traffic conditioning action that is performed at the NADs (Network Access Devices). These devices are per-flow aware and are under control of the Application Provider (AP) that signals resource requests to a QoS Provider on a flow-per-flow basis. De Clercq et al. Expires December 2003 [Page 7] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 The NAD should check whether both the resources consumed by the flows, as well as the destination of the flows comply with the resource request sent previously to the QP. This traffic conditioning action is performed by the AP on behalf of its end-users that might not be trusted to send traffic behaving according to what had been requested before. A QP is not capable to detect individual misbehaving flows as the data plane of the NP does not keep per-flow information. As such, the QP needs to trust the fact that the flows entering his QoS pipes have received appropriate traffic conditioning at the NADs from the originating APs. Therefore the entities that participate in this architecture need to trust the fact that they all conform to this specification. As an obvious way to protect themselves, a QP can always know whether an AP is not respecting the trust specification by comparing the aggregate incoming resources from each AP with the requested resources asked by each AP. This aggregate monitoring information can be obtained from measurements done by the NP and communicated to the QP. If there would be a mismatch the QP can decide to terminate the peering agreement with that particular AP. This in itself should be an incentive for all APs to perform the appropriate traffic conditioning at their NADs such that the QoS characteristics of the traffic requests match with the effective resources consumed by the traffic sent over the QP's overlay network. This trust specification is crucial to avoid per- flow awareness in routers of the core network owned by the NP and also applies to a multi-domain/multi-provider context as we will see in the next section. 3.2 Concatenation of QoS pipes It is feasible for a single network to provision and maintain QoS pipes between its edge routers. One set of QoS pipes results in an overlay QoS-aware network. It is not feasible though to provision end-to-end QoS pipes on an Internet-wide scope, in order to achieve global reachability. The enormous number of ingress-egress pairs and the n-square nature of the problem implies that this approach wouldn't scale. Moreover, end-to-end pipes would need to be supported by different backbones managed by different network providers. In order to overcome this problem, the proposed end-to-end architecture consists of a network of local (intra-domain) QoS pipes and concatenation points between the pipes belonging to different domains. These local QoS pipes can autonomously guarantee QoS. At every concatenation point, for data packets leaving a certain pipe, a selection of the next pipe to send data packets through needs to be performed. As a concrete example, the concatenation points could be the border routers of the Autonomous Systems (AS's), as shown in De Clercq et al. Expires December 2003 [Page 8] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 figure 2. In this way, end-to-end flows will transit a sequence of pipes and the resource availability should be checked (before a particular flow can be admitted in the very first pipe) for every pipe in the sequence by the corresponding service provider owning the pipe or the overlay network to which the pipe belongs. <- autonomous system 1 -> <-- autonomous system 2 --> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | | | __|_ |_ _| _|__ | | | | | |-------------------| | | |----------------| | | | QoS pipe 1 | | | PE | local QoS pipe |BR |---|BR |-------------------| PE | | |----------------| | . | |------------ | | | | | | . | | QoS pipe 2 \ | | |____| |__ | . |__ |---------\ \ |____| | | . | \ \ | | | . | _\___\_ | |_ _ _ _ _ _ _ _ _ _| . |_ _ _ _ _ | |_ _| . | PE/BR | . |_______| {___.___} V concatenation point Figure 2: QoS pipes and concatenation points. In order to achieve this, the different QPs that operate the overlay networks (and thus use the QoS pipes) on top of the traversed backbones need to agree on peering agreements. These peering agreements specify the level of QoS that is being offered by the overlay network, and the policy for the exchange of reachability information. Note that these peering agreements between service providers don't specify the amount of (bandwidth) resources that might be made available to each other. Only the *level* of QoS that *admitted* flows will receive is specified; the admission of flows is done on a per-flow basis. This architecture does not require bandwidth agreements between peering NPs or peering QPs. In order to implement such an inter-service provider behavior, a selective route distribution system is necessary. Indeed, the exchange of reachability information should only be performed between De Clercq et al. Expires December 2003 [Page 9] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 those service providers that have a peering agreement, irrespective of the physical peering points between network providers. This selective route distribution will also guarantee that packets are routed end-to-end along an unbroken chain of QoS pipes, even if there would be alternative routes without these QoS pipes. This implies that the routing for traffic requiring QoS and the routing for best effort (BE) traffic needs to be separated as both may not coincide: BE routes are determined by the peering agreements between Service providers that own BE SLSs while QoS routes are determined by the peering agreements between QoS providers that own QoS SLSs. Note that within every of the traversed networks (or network parts), QoS is only assured for each of the QoS pipes that reach from an ingress point of the network to an egress point of the network. It is the NP who offers this assurance by policing the traffic that uses the QoS pipes on an aggregate level. The QP will compare the aggregate incoming traffic from its peering QPs (based on monitoring information received from the NP) with the aggregate resources requested by these QPs. If there is a mismatch, the QP might decided to terminate the peering relation. Therefore every QP will carefully monitor the trust specification with its APs and QPs, otherwise he runs the risk to loose his peering relation with other QPs. As such every business player in the chain (AP-QP-...-QP-AP) has a strong incentive to respect the trust specification, and per-flow traffic conditioning can be restricted to the access (traffic ingress) and should not be repeated in the core networks at every peering point between different providers. As such the trust specification is key to preserve the scalability of the end-to-end architecture. 3.3 Data/control plane separation This architecture clearly separates the functionality of the flow control plane from the functionality within the data plane. This separation is not only logical but also effectively imbedded in the architecture, which, as we will see later on, leads to enhanced scaling properties and to an acceptable deployment strategy of the approach in existing network infrastructures. The architecture also maps two different ''roles'' on these separate functions in the core of the network. The flow control plane role belongs to the QP, while the data plane role belongs to the NP. Note again that both roles may be effectively played by different (business) entities, or that alternatively, the same entity may De Clercq et al. Expires December 2003 [Page 10] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 perform both roles. One of the key requirements for an end-to-end QoS solution is that there should not be per-flow awareness in the data plane in the core of the network. By deploying the two-level admission control explained in section 3.1 and by clearly separating the data plane from the control plane throughout the architecture, the per-flow awareness can be limited in the data-plane to the ingress NADs and to the control plane of the different involved APs and QPs. The clear split between control plane and data plane has the advantage that the signaling protocol should not be implemented on the routers but can be implemented on a centralized device. This has the additional advantage of leading to an approach that can be more easily deployed in existing networks: no existing network elements need to be upgraded with newly defined per-flow control plane functions. In this architecture, every QP has a specific QoS controller. When a request for a new flow is processed, the QP's QoS controller needs to find out which QoS pipe in its overlay network will be impacted, in order to be able to perform the required per-flow admission control. Therefore, the view of the flow signaling plane (the control plane) on the network's reachability information needs to be aligned with the reachability information maintained and used in the data plane. In a multi-domain scenario, the QP's QoS controller needs to find out which QoS pipe in its overlay topology will be affected by a new flow (in order to perform per-flow admission control), and then it needs to send the flow request to the QoS controller of the QP with which it has a peering agreement in the next impacted network (the ''next- hop'' QoS controller). The QP's QoS controller can identify the impacted QoS pipe and the ''next-hop QoS controller'' using the QoS request's destination information, because the information it has on the global reachability is aligned with the reachability information in the data plane (in the NP's routers). De Clercq et al. Expires December 2003 [Page 11] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 ___________ ___________ AC---> | QoS contr | --AC-> | QoS contr |-----AC / ----------- ----------- \ | _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Q-I | | | | Q-R _____ _|_ overlay |_ _| overlay _| _____ |S-NAD|-|PE | of |BR|--|BR| of |PE|-|D-NAD| ----- |___| QoS |__| |__| QoS |__| ----- | pipes | | pipes | |_ _ _ _ _ _ _| |_ _ _ _ _ _ _| Figure 3: admission control in a multi-domain scenario. 4. VSN in a single-domain core network 4.1 Provisioning of QoS pipes In a first phase, the QP requests QoS pipes between the NP's edge routers (PEs) to which it has NADs attached. The NP then checks whether it has enough resources available in its network to fulfill these requirements, and if so, provisions QoS pipes between its PEs according to the requested SLS. The NP effectively implements this behavior using any existing mechanism, for example using the DiffServ capabilities of its network, by using the QoS capabilities of the supporting Layer-2 network, or for example by establishing traffic-engineered LSPs. From this point on, the NP performs traffic conditioning on the aggregate traffic that enters the QoS pipes, in order to accomplish the behavior specified in the SLS. The NP's PE devices need to decide about which traffic to send over which overlay network over its core network as there could be multiple overlay networks owned by multiple QPs. This could be statically configured, as the AP's NADs are statically attached to the PE devices and all traffic coming from a specific NAD will probably go to one overlay network only, as part of the peering relation between the AP and a particular QP owning that overlay network. This decision is thus made on the basis of the incoming (sub-)interface. The NP's PE devices need also to decide about what traffic to send on which particular QoS pipe in a particular overlay network. According to the granularity of the PE's view of the traffic (PEs need not be per-flow aware), these PEs need to make this decision on an aggregate level, i.e. via normal IP forwarding. 4.2 Per-flow admission-control De Clercq et al. Expires December 2003 [Page 12] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 As mentioned previously, in this architecture, every QP maintains a central control plane element that keeps track of the available resources in the leased QoS pipes and that controls the admission control of new flows. This central control element will be called ''QoS controller'' (QC) throughout this document. When the QP needs to process a request for a new flow with associated resource guarantees, the QC needs to do the following: a. associate the considered request with a specific QoS pipe. The QC uses its view on the overlay topology and its view on the according routing information, together with the flow's source/destination information specified in the request, to make the required association; b. check this identified QoS pipe for available resources. Indeed: the QC has the necessary information on the total reserved resources of the leased QoS pipes (as specified in the SLS's), and on the resources consumed by existing flows. This information is compiled based on the granted resource requests for ongoing flows and is not based on the monitoring of the loading on each QoS pipe. Monitoring information is only used for consistency checks in the framework of the trust relation between service providers c. if the new flow's requested resources can be assured, the flow is admitted, and the QC's view on the available resources in the QoS pipe must be adjusted accordingly. Admitted flows will then be conditioned (policed, etc.) at the AP's NAD. 4.3 Route Alignment From the above description it follows clearly that the proposed solution can use an out-of-band (flow establishment) signaling protocol. An important concern when using out-of-band signaling as proposed, is the fact that the flow control plane must know the exact routing information that will be used by the data packets (the routing information in the routers' routing and forwarding tables). Indeed, the routers' routing and forwarding tables dictate which path the flows will take through the network. And, as was explained earlier, the QC needs to know this information to be able to associate a specific request for a QoS flow with the appropriate QoS pipe. De Clercq et al. Expires December 2003 [Page 13] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 One can think of different mechanisms to align the control plane's view on the network's routing information with the effective data plane's routing information. One method is by statically configuring routing information in the QC. Other methods will be described further in this document. 5. VSN in a multiple-domain core network When sending an end-to-end flow over a multi-domain core network, we need to deal with an environment where services are not offered by a single AP or QP, and where traffic flows are not delivered using only one NP's infrastructure. The VSN architecture described in this document creates overlay topologies over single-domain networks. In a multiple-domain environment, every domain will implement the single-domain VSN behavior described in the previous sections. VSNs (operated by QPs) in neighboring domains that offer the same QoS guarantees will establish peering relationships. As such, a multi- domain QoS-aware network of pipes and concatenation points is created. Now one must make sure that QoS packets are forwarded along this concatenation of QoS pipes and concatenation points. Therefore a specific routing context must be created for this multi-domain QoS- aware network of pipes and concatenation points, sharing the same level of QoS. PE-based VPNs are a way of creating specific separate routing contexts in a single-domain network. BGP/MPLS VPNs [2547bis] are one implementation of PE-based VPNs (section 5.1). VR-based VPNs are another implementation of PE-based VPNs (more details in a next version of this document). An advantage of the use of tunneling as in [2547bis] is that the routing information pertaining to the different contexts are kept out of the core (P) routers. An additional advantage of the use of MPLS as a tunneling technique is the ease of protection and restoration and the ability to optimize networking through the use of explicit routed tunnels. The architecture does not mandate the use of MPLS nor BGP/MPLS VPNs. Indeed, there is no architectural reason why VSNs could not work with with an IP QoS solution. A discussion on an IP QoS-based implementation of the architecture is given in section 5.2. 5.1 BGP/MPLS VPN application De Clercq et al. Expires December 2003 [Page 14] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 VPNs effectively implement separate routing contexts over a shared network. Every customer (e.g. an enterprise) buying a VPN will be handled in a different separate context, as such achieving routing information segregation and user data segregation. In this architecture, a QP can buy a VPN (or more precisely, a context, implemented as a VPN) to offer a certain level of QoS. This allows for a clear separation of the traffic requiring QoS and the BE traffic over one and the same network infrastructure. As such, the introduction of a QoS-enabling architecture as described in this document, will not be disruptive for the existing BE Internet. In order to achieve the requested end-to-end behavior, following the general VSN requirements, a certain form of ''stitching'' of VPNs will be needed between VPNs in different domains where the corresponding VSNs (or QPs) have a peering agreement. Note that the terminology used in this specification differs from the normal ''VPN terminology'': in this specification, a QP buys a VSN (VPN) from a NP, while in VPN-terminology, a customer buys a VPN from a SP. Note that although BGP/MPLS VPNs are introduced here as a possible implementation of VSNs in the context of multiple-domain networks, BGP/MPLS VPNs can also be used as an implementation in a single- domain scenario. 5.1.1 Creation of arbitrary overlay topologies The overlay topology that the QP leases from the NP (i.e. the set of QoS pipes) will thus be effectively implemented using BGP/MPLS VPNs: - every PE that serves as an ingress or egress of a QoS pipe from a certain QP, will implement a Virtual Router (or a VRF, in BGP/MPLS VPN terminology) dedicated to the corresponding VSN; - the routing information will be selectively distributed using MP-BGP to those VRFs that belong to the appropriate (QoS) context, using the filtering on Route Target attributes described in [2547bis]. The VSN architecture as it is currently described, only needs the basic ''fully meshed VPN'' mechanism of [2547bis], the applicability of more complex scenarios such as ''hub and spoke'' topologies is for further study. De Clercq et al. Expires December 2003 [Page 15] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 5.1.2 VPN peering at border routers The border routers of two interconnected networks that support the VSN architecture, will also need to implement the [2547bis] PE behavior. Moreover, the neighboring border routers' VRFs that ''belong'' to QPs (or VSNs) that have a peering agreement (in other words, those VRFs that ''serve the same context'') need to be somehow attached to each other via a specific (sub-)interface. This can be a statically configured (sub-)interface such as an ATM PVC, an Ethernet VLAN or a direct link. Alternatively, this may be a dynamically established single-hop LSP as will be explained later. By locally attaching the ''peering QPs'' VRFs of the border routers of peering domains to each other, VPNs of the same context, operating in neighboring domains, are effectively stitched together (keeping the same context). In addition, as IP lookups will be performed in these border routers' VRFs, they perform the ''concatenation point function'' that this architecture needs. The exchange of per-QoS context reachability information between the peering VSNs in neighboring domains can be implemented in various ways. As BGP is intensively used in [2547bis], and as E-BGP is the most popular inter-domain routing protocol, E-BGP is the ideal candidate for doing so in this architecture. BGP/MPLS VPN proposes 3 approaches for the implementation of inter- domain VPNs (see [2547bis], section 10). The BGP/MPLS VPN (scaling) requirements for the inter-domain behavior of VPNs are different though from the requirements put forward by this architecture. In BGP/MPLS VPNs, the assumption is that it is probable that a very large number of VPNs need to be supported by every network, and as such that two peering networks might also have a large number of VPNs in common. Therefor the architecture is optimized in such a way that VPN routing information is only to be maintained in PE routers that directly attach to customer sites, and as such not in autonomous system border routers. A result of this design is that ''end-to-end'' (as in ingress PE (AS1) - egress PE(AS2)) BE LSPs need to be established between PEs that are attached to the same VPNs. On the other hand, in this VSN architecture, it is assumed that only a limited number of VSNs need to be supported per network, and as such that two peering networks will also have only a very limited number of peering QPs. In addition, it is assumed that every AP will have a large number of ''access points'' in the networks to which their NAD's are attached. Therefore the architecture is optimized in such a way that end-to-end tunnels (e.g. LSPs) are avoided, resulting in the need for a (very limited) number of VRFs in the attachment De Clercq et al. Expires December 2003 [Page 16] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 points. In the context of this architecture, option (a) in section 10 of [2547bis] (''VRF-to-VRF connections at the AS border routers'') is the optimal solution for the stitching of VPNs in different domains. _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | | | _| _|_ _|_ _|_ ___ | | | |-EBGP->| | | | ___ |NAD|-|PE1|--IBGP-->|PE2|_______|PE3|--IBGP--->|PE4|-|NAD| --- |___| |___|___ |___| |___| --- | |\ \ | | |_ _ _ _ _ _ | \ \ |_ _ _ _ _ _ _| EBGP \ _ _ _ _ _ _ \ _\_| |__ -->| | | | ___ |PE5|--IBGP-->|PE6|-|NAD| |___| |___| --- |_ _ _ _ _ _| Figure 4: inter-domain routing distribution. As border routers are configured as BGP/MPLS VPN PE routers, they will participate in the BGP-based routing exchange of VPN-routes. By filtering on Route Target attributes, the border routers will insert the routes received from their I-BGP peer PEs in the appropriate VRFs. Following normal BGP behavior, a border router will then, if necessary, send a BGP UPDATE message containing reachability information via E-BGP to its neighboring border router. In order to keep this BGP update in the correct context, different methods are possible: - VRFs are directly attached and both border router PEs treat each other's VRF as a CE; normal unlabeled IPv4 routes are exchanged via E-BGP (as in [2547bis], section 10, option a); - directly attached border router PEs treat each other as PE routers, and send each other labeled VPN-IPv4 routes via E-BGP; filtering on route target attributes assures that the routing updates are inserted in the correct VRFs; the border router PEs use the BGP-announced MPLS labels in the MPLS encapsulation of data packets they send to each other; this leads to a more dynamic ''attachment'' of VRFs. A border router PE who has been updated by such an E-BGP update, will run BGP's decision process and will then use I-BGP as described in [2547bis] to distribute the necessary reachability information to its I-BGP PE peers. De Clercq et al. Expires December 2003 [Page 17] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 5.1.3 End-to-end packet flow The implementation as described in the previous sections leads to the following end-to-end processing of data packets, once admission control has been performed. A packet flow is injected in the AP's NAD. At this node, traffic conditioning is done at a per-flow level. At the NAD, all the flows are sent to its attached PE device. In that PE device, the considered aggregate traffic is handled in a specific VRF, to which the NAD is attached (by configuration). In the VRF, packets are IP forwarded into the right LSP (corresponding with a certain QoS pipe), based on the BGP/MPLS VPN distributed routing information. The IP packets are encapsulated with a ''VPN MPLS label'', identifying the VPN context, and a topmost ''tunnel label''. The PE device performs traffic conditioning at the granularity of the QoS pipes. Packets are then tunneled towards the egress PE of the first core network. Let's assume that this PE is a border router. Based on the ''VPN label'', the data packets are forwarded into the appropriate VRF of that PE border router. In that VRF, a normal IP lookup is performed and the packets are directed towards an outgoing (sub-)interface, that is attached to a VRF of a directly attached border router of a neighboring domain. Alternatively the packets can be forwarded on an outgoing interface with the label that has been announced by the attached border router in a labeled VPN-IPv4 E-BGP message; that border router in the neighboring AS will then use this label to send the packet to the appropriate VRF. Next, in the VRF of the second border router (that is the ingress PE of the next network), an IP lookup is performed in order to send the packet into the correct LSP (or QoS pipe) towards its egress PE in that particular network. This sequence of actions is iteratively performed until the packets finally arrive at the ultimate egress PE and are sent towards the destination NAD. 5.2 IP QoS application Even though the BGP/MPLS VPN implementation described in the previous section offers many advantages for the implementation of the VSN principles, we cannot and need not require or assume ubiquitous deployment of MPLS or BGP/MPLS VPN techniques throughout the Internet. De Clercq et al. Expires December 2003 [Page 18] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 The essential requirement is the availability of different routing contexts for different QoS classes. This can be implemented by any means allowing the storage of multiple BGP routing table entries in a router. For deployment reasons, intra-domain tunneling can be seen as a very important requirement as well, in order to keep the different routing context out of the intra-domain provider core routers. There are several ways of implementing intra-domain tunnels without MPLS (including GRE, IP-in-IP and IPsec). A detailed description of a VSN implementation based on IP QoS only is left for a future revision of this document. 5.3 Dynamic data/control plane alignment As was explained earlier, the QC needs to perform multiple tasks when performing admission control in a multi-domain scenario. For a received flow admission request, it needs to (i) find the corresponding QoS pipe in the overlay topology (VSN) it operates; (ii) decide whether the considered single-domain QoS pipe can support the additional flow; (iii) identify the ''next hop VSN'' that will support the considered flow, and as such identify the ''next hop QC''; (iv) send the flow admission request to the identified ''next hop QC''. This sequence of actions is iteratively performed up to the destination network's QC, and the considered flow is only to be admitted if all the involved QCs have admitted the flow in their overlay topology. In order to perform (i) and (iii), the QC needs to have a consistent view on the forwarding decisions that will be made in the concatenation points (in the VRF of the ingress PE and in the VRFs of every traversed border router). One possible solution to achieve this, would be to require the PE devices to establish an additional BGP session. Their peer for this BGP session will be the QP's QC. Alternatively, a Route Reflector-QC BGP session can be used for this purpose too. From the PE's point of view, two implementations are possible: the QC can be seen as a CE device belonging to the considered VPN (E-BGP will then be used); alternatively, the PE can consider the QC as an extra PE device (and thus BGP/MPLS VPN-based I-BGP will be used). Note however that, in order to provide the QC with a consistent view of the BGP routing information, the BGP NEXT_HOP information would need to be preserved in the BGP UPDATE sent to the QC. Note also that the QC will only perform a passive role with regards to BGP. The QC will never send UPDATE messages, it will only passively snoop on the exchanged reachability information, and build its view on the network's routing from this snooped information. De Clercq et al. Expires December 2003 [Page 19] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 Alternative methods for dynamic data/control plane alignment are TBD. _____ _____ :---> | QoS |<--: :--> | QoS |<----: : |contr| : : |contr| : : ----- : : ----- : BGP BGP BGP BGP : _ _ _ _ _ _ : : _ _ _ _ _ _ _ : : | |: : | |: :_| _|:_ :_| _|:_ ___ | | | |-BGP->| | | | ___ |NAD|-|PE1|---BGP-->|PE2|______|PE3|---BGP--->|PE4|-|NAD| --- |___| |___|___ |___| |___| --- | |\ \ | | |_ _ _ _ _ _ | \ \ |_ _ _ _ _ _ _| BGP \ _ _ _ _ _ _ \ _\_| |__ -->| | | | |PE5| |PE6| |___| |___| : |_ _ _ _ _ _| : : : BGP _____ BGP :--->| QoS | : |contr|<---: Figure 5: inter-domain route distribution and alignment. 6. The QoS signaling protocol The QoS signaling protocol should allow for setup, refresh and tear- down of (QoS) bandwidth reservations in one or more IP network(s). Using the NSIS terminology, the protocol is said to be used between the QoS Initiator, QoS Controller(s) and the QoS Receiver. The important consequence of the VSN architecture on the signaling protocol is that QoS controllers are not necessarily located in routers. Consequently, the QoS controller chain for a QoS request is no more necessarily on the date path. This property of the signaling is called ''off-path'', while ''classical'' IP signaling like RSVP is called ''on-path''. General requirements for signaling were developed in the NSIS working group [Brunner], and also apply on off-path signaling. For a discussion on the advantages and issues with off-path signaling, we refer to [Couturier]. 7. Gradual VSN deployment De Clercq et al. Expires December 2003 [Page 20] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 The primary design goal that this proposal has respected, is the requirement that the proposed approach could be easily deployed in a gradual way in the existing BE Internet: the proposed mechanisms should be non-disruptive. This means among other things that it doesn't require all the deployed network elements to be updated for the solution to work, and that the solution brings added value even if only a very limited part of all the existing networks have implemented the described approach. The following properties of the described approach illustrate this. - VSNs only use tunnels (LSPs) within the boundaries of a single domain: the architecture doesn't require inter-domain LSPs; - VSNs rely on core networks that combine the DiffServ architecture with the application of admission control on aggregate traffic flows at the network edges in order to assure QoS in a single domain; - VSNs can use an out-of-band signaling protocol in order to perform admission control for an end-to-end flow. As such, this only impacts the control plane devices (the QCs), and not the existing routers; - VSNs can use the widely deployed PE-based VPN architecture as an implementation of the necessary context separation and selective route distribution. As such, the VSN architecture allows for the gradual deployment of a QoS-aware overlay internetwork without impacting the current BE Internet. Every additional network that adopts the described concepts will enlarge the reach of the QoS-aware internetwork, while backbone networks that haven't adopted this architecture keep offering today's services and keep playing their role in today's BE Internet with today's BE peering relationships. 8. VSN assurance 8.1 Performance monitoring Performance monitoring is defined as the acquisition of measurement information from the network regarding the evolution of performance parameters such as delay, delay variation, packet loss, throughput, availability, etc. This information can be used to provide feedback on actual QoS levels achieved in the network, either to a customer or for internal use in a feedback loop towards provisioning. There are essentially three ways in which monitoring can be achieved: De Clercq et al. Expires December 2003 [Page 21] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 through concatenation of per-hop or per-segment information, through active measurement by injecting dedicated test traffic or through offline analysis of traffic traces. The choice of an intra-domain monitoring method is irrelevant to the VSN architecture since it is essentially a local decision of the Network Provider. It is not clear if, and how, end-to-end monitoring should be provided. It is not inconceivable that an end-user or a Service Provider would like to monitor the actual QoS obtained for his flows. It is also possible that the end-user or Service Provider will merely detect service degradation but that the Service Provider or the Network Provider will want to identify the responsible network. Both of these applications require end-to-end monitoring information to be available. Depending on the business and trust relations, a number of possibilities are available: - End-to-end monitoring by the customer: the customer has the capability to monitor his own performance - End-to-end monitoring by the Service Provider: the Service Provider has the capability to monitor end-to-end performance - End-to-end performance recording: in the signaling, monitoring information is passed to the QoS Initiator and/or the user - Third-party monitoring: A dedicated operator is responsible for monitoring end-to-end performance of various connections. He is recognized by both customers and providers. He must be able to identify potential misbehaving networks. All these options will have impact on the security architecture of the proposed solution. 8.2 Resilience The VSN architecture makes a clear separation between data and control plane. This means that under failure conditions, we cannot assume fate sharing between data and control plane. Data plane and control plane failures can occur separately and independently and need to be addressed as such. Data plane failures will be either internal to a domain (internal failures) or have an inter-domain impact (external failure) when either the ingress or egress border node of a domain or an inter- domain link is affected. It is reasonable to assume that (most) internal failures will be solved locally. This can be part of the SLS between Network Provider and Service Provider and can be supported by means of e.g. intra-domain MPLS protection. External failures may De Clercq et al. Expires December 2003 [Page 22] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 cause a route change, either because a different pipe and different ingress/egress link in the domain need to be chosen or because an upstream domain needs to select a different AS next hop. When the control plane is still up, this situation can be notified and treated as a normal route change. Note that the same can apply for unrecoverable internal failures. Note that it would theoretically be possible to avoid signaling impact if all domain are interconnected by at least two fully meshed border routers and resource reservation is made both on the primary and the protection path. The interconnecting links should not be part of the same Shared Risk Link Group. This situation is depicted on Figure 6. +------------+ +------------+ | | | | | +----+ +----+ | | + BR +-----+ BR + | | +----+\ /+----+ | | | \ / | | | AS1 | X | AS2 | | | / \ | | | +----+/ \+----+ | | + BR +-----+ BR + | | +----+ +----+ | | | | | +------------+ +------------+ Figure 6 depicts the inter-domain data plane resilience. Because of the data control plane separation, it is possible that while the control plane is down, the data plane is not. While this requires coordination between protective actions at both layers, it can be useful that the data plane can be left running while the control plane heals. Indeed, tearing down all flows because of a control plane failure seems a brute-force solution because of the network-wide impact. Control plane failures can be further broken down into signaling protocol failures and protocol entity failures. Signaling protocol failures should be handled by the signaling protocol itself. This means that the protocol should support reliable end-to-end delivery of signaling messages. This may require reliability both at the transport and at the messaging layer. Reliability at the messaging layer is needed for end-to-end signaling reliability when the transport layer operates by means of hop-by-hop sessions. Protocol entity failures can be handled by duplication of the control plane functionality. This requires back-up control plane entities to be discovered and synchronized during normal operation. End-host failures require special attention. When the QI is different from the end-host, QI and end-host need to be aware of each others De Clercq et al. Expires December 2003 [Page 23] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 failures. Two factors can complicate this problem. First, the QI may keep hard-state related to the end-host requests because the overhead of refreshes is deemed excessive. In this case, state refreshes can not be used as a failure detection mechanism. Second, the-end host is not necessarily a signaling protocol speaker, which means that the detection mechanism must be supported outside of the signaling protocol. The failing reservation may be part of a service consisting of multiple such flows. An obvious example is a bi-directional service. It would seem appropriate for each flow to be protected separately and for the service not to be impacted when the protection action is successful. However, it would make little sense to keep one direction up when the other goes down. This would imply notification of the QI/QR of the flows making up the service in case of unsuccessful protection. The awareness of two flows being part of a single bi-directional session is typically known at the level of the application provider and such it should be the application provider's responsibility to tear down the remaining direction when the other direction goes down. Reversion is inextricably related to resilience. It describes the behavior of a system or solution that returns from a failure condition to normal operation. In the context of VSNs, reversion for inter-domain data plane failures would mean allowing route changes for optimization purposes (going back to the original state). For inter-domain control plane failures it would mean resynchronization with repaired entities and potentially re-setup of torn down flows. 9. Security and AAA Considerations 9.1 Trust issues The VSN architecture is built on the notion of the trust model. This implies that providers trust their peers to correctly police aggregate traffic and expect micro-flows to be policed at the edge of the network. In the context of security, several other trust issues may arise. Providers must, for instance, trust their peers' network provider to correctly provision the network in order to support the overlay topology. Since they do not have a contract with that network provider, they have no way of knowing the required resources will actually be available. Providers must also trust their peers to correctly update and send protocol messages. Suppose for instance that a route record functionality is supported, which is used to route back messages along the reverse of the flow path. Suppose that, De Clercq et al. Expires December 2003 [Page 24] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 in addition, this record route information must be concealed from downstream domains. In that case, a provider has to trust his peer to encrypt part of the message. It is clear that the architecture will require a strong framework for Authentication, authorization and accounting (AAA). 9.2 Authentication, Authorization and Accounting The VSN architecture will be used to provide high-value Quality-of- Service applications over and throughout the Internet. As such, it is of prime importance to ensure that these services can be provisioned and used in a secure way by the rightful parties. Because of the trust model, the focus of the security architecture can be put on authentication and integrity. Authentication provides a way of identifying a user before access is granted to the offered service. In the VSN architecture, authentication is needed between the user and the QoS Initiator and/or the QoS Responder, between the QoS Initiator and the QoS Controller and between QoS Controllers and between the QoS Controller and the NP's network management system. Integrity ensures that what is received from a peer has not been modified by an adversary. It comprises both control plane integrity (ensuring that all signaling protocol messages are received in their original form) and data plane integrity (ensuring that data packets are unaltered during their traversal of the network(s)). 9.3 Protocol security Misusing the signaling protocol is an obvious way in which an adversary could attempt to steal resources from legitimate customers. It is therefore clear that the signaling messages need to be secured. A detailed threat analysis for a signaling protocol in the context of the Next Steps In Signaling (NSIS) working group is presented in [Tschofenig]. Some control plane functionality will give rise to additional security issues because of potential misuses. This will be the case for the peer discovery protocol and if query functionality about the capabilities of certain networks is provided. The protocol, which can operate on an Internet-wide scale, may also contain a lot of information, some of which may be desirable to keep private. Confidentiality and privacy refer to the ability to keep information hidden from certain parties in the chain. It applies to encryption of (parts of) data or protocol message in order to avoid their interpretation by other parties, keeping the identity of certain users hidden and keeping the identity of certain Service De Clercq et al. Expires December 2003 [Page 25] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 Providers hidden. As an example, it could be desirable to hide the identity of the QoS Controllers in the chain from all but their peers in order to protect their customer base. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2547bis] Rosen, E., et al., 9BGP/MPLS VPN, PPVPN WG draft, work in progress. [Tschofenig] Tschofenig, H., "NSIS Threats", draft-tschofenig-nsis- threats-01.txt (work in progress), July 2002 [RFC2990] Huston, G., " Next Steps for the IP QoS Architecture ", RFC 2990, informational, November 2000 [RFC1633] Braden. R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC3175] Baker, F., Iturralde, C., Le Faucher, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation Over DiffServ Networks", RFC 2998, November 2000. [Teitelbaum] Teitelbaum, B, Hares, S., Dunn, L., Narayan, V., Neilson, R., Reichmeyer, F., "Internet2 QBone: Building a Testbed for Differentiated Services", IEEE Network Magazine, Special Issue on Integrated and Differentiated Services for the Internet, September 1999. [Qbone] http://qbone.internet2.edu/papers/non-architectural- problems.txt [Brunner] Brunner, M., "Requirements for QoS Signaling Protocols", draft-ietf-nsis-req-04.txt (work in progress), August 2002 [Couturier] Couturier, A., and Schelen, O., "On path and off path De Clercq et al. Expires December 2003 [Page 26] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 signaling for NSIS ," draft-schelen-nsis-opopsig-00.txt (work in progress), June 2002 Acknowledgments The authors would like to thank Hans De Neve and Danny Goderis for their valuable inputs. Author's Addresses Jeremy De Clercq Alcatel e-mail: jeremy.de_clercq@alcatel.be Sven Van Den Bosch Alcatel e-mail: sven.van_den_bosch@alcatel.be Francis Wellesplein 1 2018 Antwerpen Belgium Alban Couturier Alcatel e-mail: alban.couturier@alcatel.fr Ets de Marcoussis R&I/ULC Route de Nozay 91461 Marcoussis CEDEX, France Full Copyright Statement "Copyright (C) The Internet Society (date). 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 De Clercq et al. Expires December 2003 [Page 27] Internet Draft draft-declercq-vsn-arch-01.txt June 2003 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. De Clercq et al. Expires December 2003 [Page 28]