Internet DRAFT - draft-halstead-guichard-mavs-requirements
draft-halstead-guichard-mavs-requirements
TBD M.Halstead, Ed
Internet Draft Nexagent Ltd
Expires: November 2006
Jim Guichard, Ed
Cisco Systems, Inc.
Christian Jacquenet, Ed
France Telecom
May 8, 2006
IETF Internet Draft
Document: draft-halstead-guichard-mavs-requirements-02
Requirements for Multi Autonomous System VPN Services
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Expires November 8, 2006 [Page 1]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
Abstract
This document complements [RFC-4031] and defines requirements that
are specific to the delivery of BGP/MPLS-based [RFC-4364] VPN
services across multiple administrative domains. These requirements
are independent of underlying technologies or the number of
Autonomous Systems such VPNs may span. It lists the requirements of
the different parties that are involved in the administration of
these Autonomous Systems and may therefore be involved in the
delivery of the VPN service offerings.
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].
Table of Contents
1. Introduction................................................4
2. Gap Analysis Summary by IETF Working Group...................7
2.1. Internet Area..........................................7
2.1.1. L3VPN Working Group Work Items.....................7
2.2. Operations and Management Area..........................7
2.2.1. Netconf Working Group Work Items...................7
2.3. Routing Area...........................................7
2.3.1. PCE Working Group Work Items.......................7
2.4. Transport Area.........................................8
2.4.1. IPPM Working Group Work Items......................8
2.5. Security Area..........................................8
2.5.1. BTNS Working Group Work Items......................8
2.5.2. PKI4IPSEC Working Group Work Items.................8
2.5.3. SIDR Working Group Work Items......................8
2.6. Requirements not addressed by any Working Groups.........8
3. Definitions.................................................9
3.1. Multi Domain Environment (MDE)..........................9
3.2. VPN Service Provider (VSP)..............................9
3.3. VPN Peering Location (VPL)..............................9
3.4. Agent..................................................9
4. Problem Statement..........................................10
5. Multi Domain Environment Reference Model....................11
5.1. Distributed Policy Enforcement Example.................12
5.2. Centralized Policy Enforcement Example.................12
6. Topological Requirements....................................12
Expires November 8, 2006 [Page 2]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
6.1. Remote Service Interconnect Requirement................12
6.2. Optimal Interconnect Selection Requirement.............13
6.3. Redundant Interconnect Requirement.....................14
6.4. VPN Topology Requirement...............................15
6.5. End-to-end Unicast and Multicast Routing Requirements...16
6.5.1. Generic Routing Considerations....................16
6.5.2. IGP Routing Considerations........................16
6.5.3. BGP Routing Considerations........................17
6.5.3.1. BGP AS_PATH Attribute Considerations..........17
6.5.3.2. Route Distinguisher Allocation Considerations.17
6.5.3.1. Route Target Allocation Considerations........18
6.5.3.2. Traffic Load Balancing Considerations.........18
6.5.4. Multicast Routing Considerations..................19
6.6. Topological Requirements Gap Analysis..................19
7. QoS Requirements...........................................20
7.1. Differentiated Services Policy Considerations..........21
7.1.1. QoS Policy Transparency...........................22
7.2. Consistent Metric Considerations.......................22
7.3. Traffic Engineering/Routing Policy Considerations.......23
7.4. Metrology Considerations...............................23
7.5. QoS Requirements Gap Analysis..........................24
8. Security Requirements.......................................25
8.1. Security Information Requirements......................25
8.2. Encryption Requirements................................26
8.3. Label Spoofing Protection..............................27
8.4. Authentication Requirements............................27
8.4.1. Authentication of Network Elements................27
8.4.2. VPN Route Authentication and Filtering............27
8.5. Security Requirements Gap Analysis.....................29
9. Management Requirements.....................................29
9.1. Performance Metric Statistic Requirements..............29
9.2. Capital Scaling Requirements...........................29
9.3. Operational Scaling Requirements.......................30
9.3.1. Service Independence Requirements.................30
9.3.2. Minimize Network Integration Requirements..........30
9.3.3. Third Party Interconnect Requirements.............31
9.4. IPVPN Services Demarcation Requirements................31
9.4.1. Fully Managed Service Demarcation.................31
9.4.2. Mixed Management Service Demarcation..............32
9.5. Remote CE Management Requirement.......................32
9.6. End-to-End Combined Services Requirement...............33
9.6.1. Combined VPN and Internet Access Requirement.......33
9.6.2. Combined IP and non-IP Application Transport
Requirement.............................................34
9.7. Management Requirements Gap Analysis...................34
10. Conclusions...............................................35
11. Acknowledgements..........................................37
Expires November 8, 2006 [Page 3]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
12. References................................................37
12.1. Normative References..................................37
12.2. Informative References................................38
Editor's Addresses............................................39
13. Intellectual Property Statement............................39
Disclaimer of Validity........................................40
Copyright Statement...........................................40
1. Introduction
This document summarizes requirements that apply to all parties
involved in the delivery of BGP/MPLS-based [RFC-4364] VPN services
that span multiple Autonomous Systems (ASes). Such parties include,
but are not limited to, Network Service Providers (NSP), Systems
Integrators (SI), Network Integrators (NI), Cable Operators (CO),
Mobile Operators (MO) and Virtual Network Operators (VNO). This
document further specifies which current IETF working groups could
host the work items that address some or potentially all of the
identified requirements.
BGP/MPLS-based [RFC-4364] VPN services may be delivered between ASes
of the same company (commonly referred to as ''Inter-AS'' services),
or different companies (commonly referred to as ''Inter-provider''
services). This document aims to provide requirements for either
type of service delivery.
BGP/MPLS-based [RFC-4364] VPN services are deployed and operated due
to the combined activation of a set of elementary capabilities. This
document is organized to take the requirements for activating these
capabilities across multiple ASes into account using the following
taxonomy:
- Topological considerations: These correspond to the information
needed for the deployment of BGP/MPLS-based [RFC-4364] VPN
topologies. This information includes, but is not limited to,
identification of the endpoints that will be interconnected via
the VPN, forwarding and routing policies to be enforced by the
VPN network elements, and the topology of VPN membership.
- QoS considerations: These correspond to the information, with QoS
parameters, that may characterize the level of quality provided
with the VPN service offering. QoS parameters include, but are
not limited to, VPN traffic classification and marking
capabilities, traffic conditioning and scheduling capabilities,
as well as VPN traffic engineering capabilities.
Expires November 8, 2006 [Page 4]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
- Security considerations: Any BGP/MPLS-based [RFC-4364] VPN that
is deployed and operated across multiple ASes may require the
need for identification, authentication and potentially, VPN
traffic encryption capabilities. This includes the possible
identification and authentication of the resources that
participate in the establishment and operation of a VPN, as well
as the ability to check the integrity of VPN route announcements
exchanged between ASes.
- Management considerations: It is assumed that the operation of
QoS-based BGP/MPLS-based [RFC-4364] VPN services is part of the
management tasks performed by service providers within their own
ASes. Additional operational tasks are however needed in order to
enable the management of VPN services across multiple ASes.
- Measurement and monitoring considerations: the ability to measure
and monitor service delivery is of paramount importance,
especially when such services span multiple ASes.
This document is therefore organized as follows:
- Section 2 is a gap analysis summary listed by IETF working group.
The purpose of this section is to summarize all requirements
identified in this document by each working group, with a
reference to the section that describes the requirement in full.
- Section 3 defines terminology specific to the delivery of
BGP/MPLS-based [RFC-4364] VPN services that span multiple ASes.
This terminology aims at facilitating the overall understanding
of the issues and requirements expressed in this document.
- Section 4 describes some of the drivers for the deployment of
Multi-AS BGP/MPLS-based [RFC-4364] VPN services.
- Section 5 introduces a reference model that depicts the context
for the deployment and the operation of BGP/MPLS-based [RFC-4364]
VPN service offerings that span multiple ASes. In addition, use
cases illustrate examples of different business and operational
process interaction between the various parties.
- Section 6 describes topological requirements that include traffic
forwarding and routing considerations, VPN traffic load balancing
capabilities, as well as VPN Peering Location-specific
interconnect design considerations.
Expires November 8, 2006 [Page 5]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
- Section 7 describes VPN-specific Multi-AS QoS policy enforcement
requirements which include forwarding, routing and measurement
considerations.
- Section 8 describes VPN-specific Multi-AS security policy
enforcement requirements which include identification,
authentication and encryption considerations.
- Section 9 describes VPN-specific Multi-AS management policy
enforcement requirements which include configuration, fault
detection, performance and accounting management tasks.
Sections 6 through 9 include a "gap analysis" sub-section, the
purpose of which is to better elaborate on the pending specification
work which could solicit the IETF community to discuss whether such
gaps could be addressed by the identified working groups.
Expires November 8, 2006 [Page 6]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
2. Gap Analysis Summary by IETF Working Group
The following section details the area and IETF working group
associated with each requirement. For ease of navigation, each
requirement can be referenced by section and page number.
2.1. Internet Area
2.1.1. L3VPN Working Group Work Items
- Remote Service Interconnect Requirement, Section 6.1. , page 12
- Optimal Interconnect Selection Requirement, Section 6.2. , page
13
- Redundant Interconnect Requirement, Section 6.3. , page 14
- VPN Topology Requirement, Section 6.4. , page 15
- BGP Routing Considerations, Section 6.5.3. , Page 17
- Multicast Routing Considerations, Section 6.5.4. , Page 19
2.2. Operations and Management Area
- VPN Topology Requirement (RFC4382), Section 6.4. , page 15
2.2.1. Netconf Working Group Work Items
- Topological Requirements, Section 6. , page 12
- Differentiated Services Policy Considerations, Section 7.1. ,
page 21
2.3. Routing Area
2.3.1. PCE Working Group Work Items
- Differentiated Services Policy Considerations, Section 7.1. ,
page 21
- Consistent Metric Considerations, Section 7.2. , Page 22
- Traffic Engineering/Routing Policy Considerations, Section 7.3. ,
Page 23
Expires November 8, 2006 [Page 7]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
2.4. Transport Area
2.4.1. IPPM Working Group Work Items
- Consistent Metric Considerations, Section 7.2. , Page 22
- Traffic Engineering/Routing Policy Considerations, Section 7.3. ,
Page 23
- Performance Metric Statistic Requirements, Section 9.1. , Page 29
2.5. Security Area
2.5.1. BTNS Working Group Work Items
- Security Information Requirements, Section 8.1. Page 25
2.5.2. PKI4IPSEC Working Group Work Items
- Encryption Requirements, Section 8.2. , Page 26
2.5.3. SIDR Working Group Work Items
- Label Spoofing Protection, Section 8.3. , Page 27
- Authentication Requirements, Section 8.4. , Page 27
2.6. Requirements not addressed by any Working Groups
- Specification of a format and exchange mechanisms of SLS
templates, Section 9.4.1. , Page 31
Expires November 8, 2006 [Page 8]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
3. Definitions
Some of the terminology used in this document is taken from [RFC-
4026] and [RFC-4031]. ''VPN'' in the context of this document refers
specifically to BGP/MPLS-based [RFC-4364] VPN services. In order to
clarify the requirements listed in this document, it is necessary to
further define and introduce new terminology, specific to multi
provider VPN services as follows:
3.1. Multi Domain Environment (MDE)
Two or more Autonomous Systems that may or may not be owned by
separate administrative authorities, and which are used to
interconnect service endpoints (sites) of one or more VPNs.
3.2. VPN Service Provider (VSP)
A VSP is an operator who participates in the delivery of a single
domain, or multi-domain (MDE-wide) VPN service. In delivering the
VPN service, the VSP may own a subset, or all of the participating
network elements. Examples of VSPs include Network Service Providers
(NSP), Systems Integrators (SI), Network Integrator (NI), Cable
Operator (CO), Mobile Operator (MO) and Virtual Network Operators
(VNO).
3.3. VPN Peering Location (VPL)
A VPL is a physical location where VPN services delivered by one or
more VSPs are interconnected. Examples of VPLs include a network
operator hotel, SP central offices, a collocation facility or any
building common to one or more VSPs. A VPL could be operated by a
single VSP, consortium of VSPs or a neutral 3rd-party.
3.4. Agent
For the purposes of this document, an Agent is a VSP who is
responsible for the management of multi-party business processes,
negotiations and fulfillment that allow the multi-provider VPN to
function. The Agent manages this responsibility by either
operationally complying with or coordinating policies across all
parties involved in delivering their customer's end-to-end service.
Policy compliance or multi-party policy coordination is achieved
either in a distributed or centralized manner.
Expires November 8, 2006 [Page 9]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
For distributed policy enforcement, cooperating VSPs agree upon the
enforcement of consistent policies for VPN service provisioning
purposes. In this case, end-to-end policy enforcement is distributed
across multiple VSPs, each of which is a stakeholder in the supply
and enforcement of a fixed set of policies within the shared MDE. A
VPN customer defines their VPN service requirements with an Agent
who then maps these requirements to the set of pre-agreed policies.
For centralized policy enforcement, the Agent coordinates per
customer, a set of policies related to the management of the
customer's VPN service. In contrast to a shared MDE where policy
enforcement is distributed across multiple VSPs, this Agent will
coordinate policies and integrate VPN services per customer, thereby
creating a MDE that is dedicated to the Agent's customers only. The
Agent may independently agree and manage SLSs with each partner VSP
and offer an aggregated end-to-end SLS to their customer's.
4. Problem Statement
No single network can deliver VPN services that provide optimal
price and performance for all customers and all customer locations.
For regulatory, commercial, resiliency and other reasons, customer
requirements for VPN services may not be compatible with a single
VSP owned network infrastructure.
Alternatively, some customers may have requirements for VPNs that
are difficult and/or expensive for a single VSP to deliver. In this
case the VSP has incentives to cooperate with other VSPs that may
offer similar VPN services, along with broadly compatible SLSs.
For customers (whether they solicit an Agent or not), end-to-end VPN
service delivery is paramount. Controllable, predictable and
reliable VPN service must be delivered regardless of the
characteristics of the MDE. The challenge however for the Agent in
controlling 'global' service policy in an MDE is the lack of
homogenous policies amongst VSPs and the difficulty VSPs have in
adapting their VPN service domains to the customer's Agent-defined
VPN service policy.
Expires November 8, 2006 [Page 10]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
5. Multi Domain Environment Reference Model
Figure 1 shows a generic reference model for a Multi Domain
Environment. It shows the relationships that exist between the
various parties involved in the establishment of VPN services that
span multiple VSP-administered networks.
|<------------Multi Domain Environment----------->|
| |
| Customer |
| | |
| +----------------- Agent ------------------+ |
| | | | | | |
| | VSP1 VPL1 VSP2 | |
| | ^ ^ ^ | |
| 1..n 1..n 1..n 1..n 1..n |
| V V V V V |
|Site1 <---> AS1<---> (VPL1) <---> AS2 <---> Site2|
Figure 1 MDE Reference Model
The MDE consists of sites, interconnected via ASes. ASes are then
interconnected via VPLs, within the context of delivering VPN
service offerings. There is potentially a one-to-many relationship
between VSPs and ASes, similarly there is potentially a one-to-many
relationship between VPL operators and VPLs. Note that VSPs may be
remotely interconnected, that is, VSPs do not necessarily need to be
directly connected to each other through a given VPL, as elaborated
in section 6.1.
With reference to Figure 1, the following sections detail examples
of the coordination of the various parties in the enforcement of a
set of policies. These policies relate to the provisioning of an
MDE-wide VPN service and include (but are not limited to)
addressing, routing, QoS and security.
Expires November 8, 2006 [Page 11]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
5.1. Distributed Policy Enforcement Example
The customer's Agent is a single VSP (VSP1 in this example). VSP1
manages the relationship with the customer, which includes the
specification, instantiation, possible negotiation and invocation of
the customer's SLS (Service Level Specification). Cooperating VSPs,
VSP1 and VSP2 have pre-agreed an enforced set of policies, including
the management of VPL1. The customer's requirements are mapped by
VSP1 to the pre-agreed policies of VSP1 and VSP2.
5.2. Centralized Policy Enforcement Example
The customer's Agent is a Systems Integrator (SI). The SI does not
own the network infrastructure (the VPN networking elements), but
manages the VPLs, as well as the processes involved in connecting
the VPLs with each relevant VSP owned AS. VSP1 and VSP2
independently provide customer-specific VPN services and associated
SLS instantiated templates to the SI who is then responsible for
integrating each VSP's VPN service components and
negotiating/invoking an end-to-end SLS with/for their customer.
6. Topological Requirements
6.1. Remote Service Interconnect Requirement
In an MDE, Agent(s) will select VSPs according to the needs of their
customer. VSP owned ASes may or may not be collocated at the same
VPL. For those ASes that are collocated at the same VPL,
interconnection of VPN services can take place locally. However, in
the example of an end-to-end chain of three VSP owned ASes and two
VPLs, local VPN interconnection will happen twice; once at the first
VPL (first to second AS) and once at the second (second to third
AS). Nevertheless, in some situations, the Agent may choose not to
use the VPN service of the second (middle) VSP. Instead, the Agent
may wish to interconnect the VPN services of the first and third
VSPs remotely. There is, therefore, an Agent-driven requirement to
be able to remotely interconnect services of non-collocated VSP
owned ASes in an MDE.
Expires November 8, 2006 [Page 12]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
6.2. Optimal Interconnect Selection Requirement
VSP multi-homing is the scenario in which a VSP needs to
interconnect their AS at two or more VPLs. By ensuring that traffic
passes between ASes at pre-determined VPLs, the desired end-to-end
VPN service delivery can be established and retained for any
customer sites. VSP networks can therefore be utilized more
efficiently.
As an example, consider a customer site in the middle of the USA. It
is connected to a VSP's AS that is interconnected at VPLs in both
New York and Los Angeles. In order to minimize latency, traffic must
be sent to Tokyo via the LA VPL and not via New York. From a network
utilization perspective, routing Tokyo-bound traffic via New York
incurs an inefficient, resource-consuming round trip traversal of
the USA. Similarly, the same site might also send traffic to London.
The optimal route for this traffic will be via New York rather than
LA.
Although this scenario may be taken care of by standard IP routing,
the specifics of a VSPs BGP routing policy, or traffic engineering
implementation, may force some traffic to be forwarded away from the
best path. Nevertheless, the notion of optimality should not
necessarily be expressed in terms of hop count metrics. The
selection of the optimal interconnecting points should rely upon a
variety of criteria that include (but are not necessarily limited
to):
- The minimum number of hops that need to be crossed to reach a
given (set of) VPN destination(s). Note that AS hops can be
misleading. VSPs may implement multiple BGP ASes on one or many
IGPs,
- The minimum value of the one-way transit delay to reach a given
(set of) VPN destination(s). Note that the minimum hops and one-
way transit delay may be in conflict,
- The minimum value of the inter-packet delay variation to reach a
given (set of) VPN destination(s),
- The minimum value of the packet loss rate to reach a given (set
of) VPN destination(s),
- The preservation of the confidentiality of the traffic that may
be exchanged between a given set of VPN locations,
Expires November 8, 2006 [Page 13]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
- The maximum VPN prefix length that should be announced at VPL
locations,
- The use of VPL locations that should not share network resources
involved in the forwarding of Internet traffic,
- The required traffic symmetry to allow a given source-destination
pair to be forwarded on the same path in both directions so as to
avoid packet mis-ordering,
- The available bandwidth capacity at the VPL (in the case where
overbooking policies are in effect at the VPL),
- Political considerations e.g. a given country may not allow
routing or traffic through their geography,
- Geopolitical instability e.g. a VSP should have a stability
rating as a selection criteria,
- Availability and reliability of a given VSP,
- Any combination of the above criteria.
Therefore, for multi-homed ASes, there is an Agent-driven
requirement for interconnects at multiple VPLs to be optimally
selectable for each source-destination site pair within an MDE.
6.3. Redundant Interconnect Requirement
Part of the end-to-end VPN service offering provided by one or more
Agents involves the provision of appropriate levels of redundancy
for their MDE use case. In some VPLs, where business justifications
exist, Agents or VSPs may choose to enhance interconnect reliability
by implementing a redundant interconnect complex.
The resulting interconnects might exist in the same building or in
different buildings within a city or in different buildings in
different cities. This is in addition to the Optimal Interconnect
Selection requirement in that a customer service will be designed to
traverse each redundant interconnect, rather than a specific,
optimal interconnect.
There is therefore an Agent or VSP driven requirement to support
customer services across redundant interconnects.
Expires November 8, 2006 [Page 14]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
6.4. VPN Topology Requirement
Although VSP owned ASes offer the possibility for any customer site
to communicate with any other customer site, in certain situations
this is not desirable. There are many possible reasons why a
customer might want to restrict communication amongst sites so that
their end- to-end service becomes segmented. For instance, it may be
that security is a concern or it may be that customer sites or
divisions must only use connectivity they have paid for.
Furthermore, the traffic flows associated with specific applications
may require a partial topology specifically sized to accommodate the
aggregate traffic flows.
The segmentation might need to exist on a geographical basis,
region- by-region and country-by country. Alternatively,
segmentation might need to exist on a corporate basis, division-by-
division or site-by-site. Segmentation might even exist within
customer sites. However, today, there are no standards for or
agreement of how VPN topologies are constructed amongst VSPs.
Consequently, VSPs use different methods for establishing the
logical topology of a VPN and use different schemas to define VPN
membership.
For instance, one VSP might use standard community values to
establish layer-2 topologies whilst another might use extended
community values. Yet another VSP may use a combination of both
techniques. Alternatively, VSPs may segment VPNs using layer-3
routing techniques. In fact, some VSPs might combine layer-2 and
layer-3 segmentation techniques.
Additionally, each VSP will implement a schema for VPN membership
that is proprietary, with membership values that are likely to
overlap and conflict with other VSP assigned values. VPN membership
allocation schemas tend to be difficult to modify due to the 'hard
coding' of the schema in each network operator's OSS and BSS
systems.
Conflicting VPN membership schemas and different methods for
establishing logical topologies make it very difficult for the Agent
to establish an end-to-end VPN service. Moreover, an inventory of
the topology consisting of the network elements/interfaces and set
of paths that traffic may take through the network could in addition
be difficult for the VSP to make available to the Agent.
Expires November 8, 2006 [Page 15]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
These elements will most likely constitute a partial topological
view of the network but may be sufficient and required for the
purpose of QoS policy definition.
There is therefore, a requirement to be able to establish an end-to-
end VPN topology, with assigned VPN-ID, including the publishing of
network elements and interface inventories per VSP throughout an
MDE.
6.5. End-to-end Unicast and Multicast Routing Requirements
6.5.1. Generic Routing Considerations
Routing and forwarding configuration information deals with the
decision criteria that should be taken by a network element in order
to forward VPN specific traffic according to a given VPN routing
policy. From this perspective, VSP owned network elements should be
provided as a minimum with the following information:
- Relevant metric information so that network elements can
dynamically assign these metric values. Such metric values could
be assigned on either long or (very) short-term basis. Examples
of assigned 'long-term' metrics include packet loss and delay
thresholds, usually expressed as percentiles of available
resources. Short-term metrics may include available or reserved
bandwidth, typically provided via real-time or near real-time
SNMP MIB queries. Furthermore, these metrics may be advertised as
transitive or non-transitive.
- The configuration information related to any static route that
may identify a VPN endpoint (or VPL) as the next hop to reach a
given VPN destination prefix.
6.5.2. IGP Routing Considerations
Today there are no standards for, or agreement of, how VPN routing
policy based upon the policing of the admission and distribution of
VPN routing information (classification and filtering of routing
information) is implemented amongst VSPs.
Consequently, VSPs enforce VPN routing policies within a defined
customer topology in different ways. For example, in an MDE, where
the EF-inferred IGP policy [RFC-2676] of AS1 relies upon the
computation of routes with a maximum one-way transit delay of 120 ms
in order to reach a set of destination prefixes, and AS2 defines the
equivalent EF (Expedited Forwarding)-inferred IGP policy with a
different QoS parameter (e.g. maxLossRate=0%), then there is a risk
Expires November 8, 2006 [Page 16]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
of jeopardizing the overall quality of service of the multi-AS VPN.
Conflicting routing policies amongst VSPs therefore make it
difficult to establish an end-to-end unicast routing policy
throughout an MDE.
There is, therefore, a requirement to be able to enforce a
consistent IGP routing policy throughout an MDE.
6.5.3. BGP Routing Considerations
VSP owned network elements should be provided with relevant BGP-4
[RFC-4271] reachability information, including the attributes taken
into account by the network element's route selection process in
order to decide whether or not traffic should be forwarded along a
given VPN route.
6.5.3.1. BGP AS_PATH Attribute Considerations
Where BGP-4 is used as the PE-CE routing protocol, the use of a
single private [RFC-1930] AS Number (ASN) across all customer sites
hosted by multiple VSPs could raise issues for each VSP as they
commonly use the 'as-override' command on PE-CE neighbors.
Where VPN-IPv4 routes are advertised across multiple ASes, VSP owned
public Autonomous System Numbers (ASNs) could be pre-pended to
private route updates. The 'as-override' feature will not then
operate over PE-CE IPv4 links where public and private ASN numbers
are advertised within the same VPN address prefix.
Network elements located at a VPL should therefore be capable of
removing or changing public or private ASNs from the BGP AS_PATH
attribute on a per neighbor basis. This per neighbor AS path match
and removal policy should be capable of being performed on ingress
or egress across the entire AS path.
6.5.3.2. Route Distinguisher Allocation Considerations
VPN-IPv4 routes [RFC-4364] are made unique across a domain by
combining an IPv4 address with an 8 byte 'Route Distinguisher' (RD)
value. The advertisement of RD values end-to-end between VSPs,
combined with the customer's use of private [RFC-1918] addressing
could result in Route Reflectors (RR) making incorrect best path
decisions for identical routes received from external as well as
internal PE network elements. This will occur where RD and customer
address space overlap across VSP ASes. Although the probability of
this scenario is small, the consequences could be severe and
difficult to isolate, therefore VSP owned RRs and PE's SHOULD NOT
Expires November 8, 2006 [Page 17]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
receive VPN-IPv4 routes that have RD values assigned by another VSP.
In order to ensure that RD values that transit VPLs are unique, RD
values MUST be pre-pended by a public registered AS number [RFC-
4364], section (4.1).
6.5.3.1. Route Target Allocation Considerations
VSPs usually have difficulty in provisioning extended (Route Target)
or standard BGP community values on their PE network elements that
are assigned by external parties such as the end customers Agent or
another VSP. This difficulty is due to the VSP having automated or
manual OSS systems and operational procedures that typically apply
to per VSP ASes only. These systems and processes are difficult to
change due to schema conflicts brought about by attempting to
incorporate externally assigned RT allocation schemas. In addition,
not all VSPs allocate RT values that are pre-pended with a publicly
registered ASN or IP address. RT values to be applied on VSP PEs
therefore should be assigned by the operator of the PE. In order to
ensure that BGP extended community values are unique between ASes,
RT values that are advertised across the VPL MUST be globally unique
(e.g. by pre-pending RT values with a public registered ASN). This
follows the specification detailed in the 'Identifiers' section of
[RFC-4031] and assists in the prevention of cross-connection for VPN
services.
6.5.3.2. Traffic Load Balancing Considerations
VSPs use various traffic load-balancing techniques between customer
sites to optimize traffic flows within their own ASes. As described
in [RFC-4364], this necessitates the use of different RD values
provisioned across VRFs to which the customer is multi-homed, but
the enforcement of a RD numbering policy at the scale of a MDE
should be consistent with the recommendations expressed in section
4.2 of [RFC-4364]. Similar mechanisms SHOULD be available when VSP
owned ASes are multi-homed across multiple VPLs and where the VSP
wishes to optimize customer traffic via load balancing. Such
mechanisms may require that the signaling protocol support the
advertisement of all available paths so that optimal path selection
is available as well as backup paths in case of optimal path
failure.
Expires November 8, 2006 [Page 18]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
6.5.4. Multicast Routing Considerations
IP multicast transmission schemas may be used by some applications
such as videoconferencing or TV broadcasting in order to optimize
VPN network resources.
As a result, VSP owned network elements should support multicast
routing capabilities for the dynamic establishment and maintenance
of distribution trees within the VPN and should therefore be
provisioned with the relevant yet consistent configuration
information.
There are currently however no standards for, or agreement of, an
enforcement of consistent multicast routing policies amongst VSPs.
There is therefore a requirement to be able to enforce an end-to-end
multicast routing policy for the sake of the establishment and
maintenance of consistent distribution trees throughout an MDE.
6.6. Topological Requirements Gap Analysis
Sub-sections 6.1. through 6.3. (inclusive) mostly deal with VPN
design guidelines, which could yield the publication of an
applicability statement document, as part of the VPN deployment
scenarios that are addressed by the l3vpn working group.
Section 6.4. includes requirements for the l3vpn working group. In
addition, this section motivates the need for an exhaustive
inventory of the set of VSP-specific elementary components
(interfaces, network elements, etc.) that will be used for deploying
an end-to-end VPN topology. This is the kind of information that may
be (partly) stored and maintained in the Management Information Base
described by [RFC-4382], but the global, service-wide dimensioning
of the end-to-end topology requirement may justify the specification
of a VPN service model, e.g. based upon [IYER].
Expires November 8, 2006 [Page 19]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
Sections 6.5.1. and 6.5.2. depict the need for populating the
network elements with routing policy-specific configuration
information. This requirement raises two issues:
- The means to describe, store, and maintain the routing-specific
(configuration) information that will be used by the network
elements to enforce the corresponding routing policies.
- The means to (reliably) convey such information to the network
elements.
While the latter could benefit from the work that has been conducted
by the netconf working group so far, the former (description,
storage and maintenance of configuration information) could be
viewed as part of the aforementioned VPN service model.
Section 6.5.3 lists layer-3 VPN specific attribute behavior
requirements which could be addressed by the l3vpn working group.
Section 6.5.4. elaborates on inter-AS multicast VPN requirements
that could be addressed by the l3vpn working group.
7. QoS Requirements
Quality of service is a very generic term, which is sometimes
misused, especially when applied to IP/MPLS environments. In this
document, the design and the enforcement of a QoS policy within VPN-
specific MDE environments relies upon the following dimensions:
- A forwarding dimension, which consists of ensuring that a VSP
owned network element behaves differently, depending on the kind
of traffic it has to process and subsequently forward. This
yields a need for VPN traffic identification, classification and
possibly activation of traffic conditioning, policing, scheduling
and optionally, discarding mechanisms. The forwarding dimension
of a QoS policy is a notion that is local to a network element,
independent from the expected behaviors of the other network
elements within the MDE. The DiffServ (Differentiated Services)
architecture, as described in [RFC-2475], is generally seen as
the cornerstone of the forwarding dimension, introducing the
notion of classes of service as well as Behavior Aggregates (BA).
- A metric definition dimension, which consists of defining
consistent metrics such as delay, jitter and loss, so as to
support QoS meaningfully across multiple VSPs.
Expires November 8, 2006 [Page 20]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
- A routing dimension, which consists of enforcing a VPN-specific
traffic engineering policy at the scale of a MDE. Traffic
engineering is a set of capabilities that allow the (hopefully
dynamic) computation and selection of paths that will be used to
convey different kinds of VPN traffic. It may be necessary to
route QoS-sensitive traffic to different VSPs or along different
paths other than those selected by best effort traffic. Path
selection is dependant on the (QoS) characteristics of such
paths, which comply with the QoS requirements that have been
expressed and negotiated by the Agent with their VPN customers.
- A monitoring dimension, which consists of qualifying how
efficient a QoS policy is enforced within a MDE, based upon the
use and measurement of well-defined indicators. Due to the
multiple parties involved in the delivery of QoS, it is necessary
to have well defined methods for measurement of QoS, ways to
monitor the performance of different network elements, and ways
to report performance consistently among VSPs. Such indicators
include (but may not be limited to) one-way transit delay, one-
way inter-packet delay variation (sometimes called jitter), one-
way packet loss rate or any combination of such indicators.
7.1. Differentiated Services Policy Considerations
Currently, there are no standards for or agreement of service
definitions as defined in the Diffserv architecture amongst VSPs.
[RFC-3644] defines QoS policy within a single Diffserv domain as
being dependent upon three types of information:
- The topology of the network elements under management;
- The particular type of QoS methodology used (e.g. Diffserv), and;
- The business rules and requirements for specifying service(s)
delivered by the network.
These information types vary across VSP ASes. Consequently, VSPs
deploy different numbers of classes of service (COS) and specify
service definitions in proprietary ways. Fixed mappings of classes
of service between any two VSPs may result in compromised service
across the two. This is in part because fixed mappings cannot always
utilize the full service envelope available from the interconnected
VSPs (a VSP with three classes of service can only utilize 3/5ths of
the service envelope of a VSP with five classes of service).
Furthermore, fixed mappings may be adequate for some Agent's
customers, but not for others. This is because QoS policy is often
Expires November 8, 2006 [Page 21]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
applied in different ways for each application used in each customer
environment
When three or more VSP ASes are used to provide connectivity between
customer sites, two or more VPLs are required and, therefore, a
multiple, compounding service compromise exists.
In an MDE of many VSP ASes and VPLs, it is clear that numerous and
compounding compromises in service will take place and end-to-end
QoS policy enforcement may be hard to achieve.
There is a requirement, therefore, for a relationship to exist
between VSP classes of service that may vary from one customer to
another, and that can also utilize the full service envelope of all
VSPs within an MDE.
7.1.1. QoS Policy Transparency
There is general agreement that customer packets should not be
remarked (that is, have their DSCP values modified) as they transit
the MDE. At the same time, it is often necessary for the VSP to
impose a QoS treatment on customer packets that differs from that
which might be indicated by the customer's DSCP (such as is the case
for non-conforming traffic downgraded to best effort). However, even
if the packets are treated as best effort by the VSP, the customer
wishes to retain the original DSCP marking for their own use when
the packets arrive at their remote site. This requirement is defined
as "QoS transparency", where the transparency in question refers to
the tunneling of the customer QoS policy, unmodified, from ingress
to egress across an MDE. [RFC-4031] describes this requirement as a
'Carrier's Carrier' model where one VSP is the customer of another
VSP. Such a VSP should be able to resell VPN services to their
customers independent of the DSCP mapping solution employed by the
'Carrier's Carrier' VSP.
There is a requirement, therefore, for enterprise QoS policy
transparency throughout an MDE.
7.2. Consistent Metric Considerations
Currently, there are no standards for, or agreement of metric
definitions between VSPs. As an example, the Low Latency service
class is generally characterized by three network performance
metrics; latency, packet loss, and jitter. These metrics are
generally reported as two-way or one-way derived from two-way
measurements, but are generally defined differently between VSPs.
Expires November 8, 2006 [Page 22]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
There is therefore a requirement to produce service classes with
metrics that can be meaningfully concatenated, so as to provide
reasonable commonality of metrics across VSPs.
7.3. Traffic Engineering/Routing Policy Considerations
In a true MDE environment there may be many alternate paths between
customer sites. The preferred path among VSPs is typically
determined by BGP policies. However, when multiple classes of
service exist, it may be desirable to route some traffic
preferentially via VSPs who support the enhanced QoS class(es) while
best effort traffic takes the conventional route. That is to say,
there may be cases in which the current route selection capabilities
of BGP, which yield only a single best path for a given prefix, may
not be sufficient. The deployment of traffic engineering
capabilities in VPL owned network elements is of importance when
considering the joint forwarding of "triple-play" services where
data, video and voice traffic is forwarded within a given VPN.
Within a MDE, VSPs or Agents should provide configuration
information parameters that will allow network elements to choose
appropriate VPN paths to a given destination based on ''Service
Contexts''. These paths are chosen according to application-specific
constraints, available service characteristics and/or requirements.
These constraints and/or requirements may be expressed in terms of
time duration (e.g. the use of a VPN route on a weekly basis),
traffic characterization (e.g. all IP multicast traffic should be
forwarded along a set of specific VPN routes), security concerns
(e.g. use trusted network elements along the path towards specific
destinations), and/or QoS considerations (e.g. marked VPN traffic
with a specific DiffServ Code Point (DSCP) value should always use a
configured set of traffic-engineered VPN routes, or available exit
point that exhibits the desired ''Service Context'').
7.4. Metrology Considerations
Currently, there are no standards for, or agreement of, measurement
methods amongst VSPs. VSPs define measurements differently and
measure different service end points. In a MDE environment,
measurement methodology differences, particularly differences in the
statistical nature of the measurements, make it impossible to
combine VSP measurement reports so that the overall quality of the
VPN service can be qualified.
As VSP reports can be so different, it is tedious and time consuming
to analyze whether an individual VSP or VPL operator has met its
Expires November 8, 2006 [Page 23]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
performance targets. When end-to-end services fail, it may be very
difficult to analyze VSP measurement data in order to detect and
isolate faults amongst VSPs or VPL operators.
In an MDE, where the customer's Agent(s) are responsible for end-to-
end service, this may be untenable. In addition, whilst windows for
scheduled and unscheduled maintenance will remain difficult for the
Agent(s) to control or coordinate, any measurement methodology must
take these windows into account in any performance assessments of
the QoS policy that are made.
There is, therefore, a requirement for statistically homogenous
measurement throughout an MDE as well as the ability to place
measurement instrumentation/sources at VPL locations in order to aid
fault detection and isolation.
7.5. QoS Requirements Gap Analysis
Section 7.1. discusses the need for exchanging QoS information
between VSPs. This assumes that such information is described,
stored, and maintained by each participating VSP, but also that a
protocol is required to exchange such information between VSP
providers. The specification of a QoS policy could be viewed as part
of the VPN service model specification effort (as mentioned in
section 6.6. ). The corresponding configuration information to be
used by the network elements to enforce such QoS policies could
benefit from the work conducted by the netconf working group. To
exchange such information between VSPs, there are several candidate
protocols which include (but are not necessarily limited to) RSVP,
BGP and the protocol to be specified by the pce working group (since
such information might be used by Path Computation Elements to
compute traffic-engineered paths).
The need for the use of consistent metrics (as described in section
7.2. ) could rely upon the work conducted by the ippm and pce
working groups (since the latter is chartered to define objective
metrics that will aim at evaluating the quality of a traffic-
engineered path, for example).
Section 7.3. describes the need for populating network elements with
routing and traffic engineering configuration information. Such
information can be viewed as part of the description of the overall
QoS policy that will have to be consistently enforced by the
participating VSP providers for the delivery and the operation of a
given VPN service. Both the netconf and pce working groups could be
solicited to investigate the corresponding (protocol-specific)
Expires November 8, 2006 [Page 24]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
issues, but this is also the kind of requirement that advocates the
specification and the instantiation of a VPN service model.
From a metrology standpoint as described in section 7.4. , the work
conducted by the ippm working group (OWAMP (One-Way Active
Measurement Protocol, [OWAMP]), and TWAMP (Two-Way Active
Measurement Protocol, [TWAMP]) protocols) could serve as a basis for
investigating the consistency issues raised by this section.
8. Security Requirements
Security is a requirement of any business, but the requirement
becomes more important where that business collaborates with others
to provide a service [RFC-4111]. Potential threats might emanate
from a number of sources, for instance, other VSPs, VPL operators
and customers.
Clearly, the vulnerability of a customer service to threats from
these sources is of paramount importance. Of equal importance is the
vulnerability of a VSP AS to threats from these sources. An attack
on a VSP AS could detrimentally affect numerous customers, including
those attached to other VSP owned ASes.
8.1. Security Information Requirements
Enforcement of a security policy at the scale of a MDE may rely upon
the following capabilities:
- The identification and the authentication of the users who may be
entitled to access the VPN service,
- The identification and authentication of network elements that
will not only participate in the deployment and the operation of
the VPN, but also in VPN route information propagation,
- The preservation of the confidentiality of information within a
VPN.
VSPs should therefore be provided with configuration information
related to the aforementioned security parameters. This does not
mean that VSP owned network elements have to maintain a dynamically
updated user database, rather, they should be provided with the
following configuration information:
- Identification information for IP networks that may exchange data
through the VPN and/or the configuration information required for
the activation of an identification/authentication mechanism such
Expires November 8, 2006 [Page 25]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
as RADIUS (Remote Authentication Dial-In User Service), [RFC-
2865],
- Identification information for VSP owned network elements that
support endpoint(s) of the MP-BGP peer and possibly configuration
information related to the activation of a mechanism for
identifying and authenticating such peers,
- Configuration information required for encryption purposes. This
requirement is further expanded on in section 8.2.
There is a requirement, therefore, to securely forward VPN related
security parameters between VSPs and Agents.
8.2. Encryption Requirements
VPN customers may require all or part of their encrypted traffic to
be preserved, independent of the number of VSP owned ASes within the
MDE supporting their VPN service.
There is therefore a need for the MDE to support any relevant
encryption technique that preserves the confidentiality of the VPN
traffic. This implies that:
- The VSP owned network elements that compose the MDE should
support protocols of the IPsec suite [RFC-4301],
- The MDE should be capable of supporting an adequate means for
identifying and authenticating any participating device involved
in the forwarding of VPN traffic,
- The MDE should be capable of supporting an adequate means for
identifying and authenticating any participating VSP owned
network element involved in the enforcement of the VPN-specific
routing policy. Such means should enable any VSP owned network
element to check the integrity of received VPN route
announcements,
- The MDE should be capable of supporting and enforcing any dynamic
key management scheme suitable for the dynamic establishment of
Secure Associations (SA) between relevant VSP owned network
elements without jeopardizing the scalability of the VPN service,
- VSPs that are involved in the dynamic establishment of SA
associations across their ASes should be provided with relevant
configuration information (keys, passwords) in a timely manner,
that is, the provisioning of such configuration information
Expires November 8, 2006 [Page 26]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
should not jeopardize the time to deliver the VPN service
offering to the customer with the required level of security (nor
its scalability).
8.3. Label Spoofing Protection
Whenever labels are exchanged between two VSP peers it is possible
that the spoofing of such labels may occur either toward the
internal infrastructure of the said VSPs, or within the VPNs that
are supported by such VSPs. There is therefore a requirement to
provide mechanisms that prevent the spoofing of labels in the
forwarding path.
8.4. Authentication Requirements
8.4.1. Authentication of Network Elements
Within a MDE, every VSP owned network element that participates in
the deployment and the operation of a VPN service offering should be
trusted. This trust model may need to be specifically defined on a
per-VSP peering basis. There is therefore a requirement to provide
acceptable authentication processes in order for a network element
to participate in the deployment and operation of a VPN service.
This implies that every VSP owned network element must be identified
and authenticated typically via processes owned by relevant Agents
or VSPs.
8.4.2. VPN Route Authentication and Filtering
Within a MDE, every VSP owned network element is permitted to
announce VPN routes to some or all of its pre-authenticated peers,
assuming the requirements expressed in section 8. 1. have been
addressed.
VSPs have existing mechanisms and operational processes that prevent
the cross connection of VPNs within their own ASes. These mechanisms
include manual or automated systems for VPN membership allocations
that include per customer RT values. Where the VSP extends VPN
services via an MDE, incorrect or malicious configuration of VPN
membership information could result in cross connection or incorrect
announcement of VPN membership attributes across an MDE. These route
announcements could in addition expose the VPN topology of the VSP.
The integrity of the contents of such VPN route announcements must
be authenticated by any receiving peer and/or by some kind of VPN
route server capability that could be embedded in the relevant Agent
or VSP owned facility before the receiving peer accepts the
Expires November 8, 2006 [Page 27]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
announced route. Draft [VPN-VERIFICATION] could assist with this
route authentication requirement.
It should be possible to enforce further VPN route-specific
filtering policies at appropriate locations within an MDE.
Additional route filtering criteria could be based upon (but not
necessarily limited to):
- Intra-VPL communication restriction where, for example, RT value
announcements are filtered such that they only include interested
parties across VPL locations. This filtering policy is
particularly relevant where the VSP owned network elements peer
with more than one network element at a VPL. This function is
described further in [RT-CONSTRAIN]
- Intra-VPN communication restrictions, where, for example, not all
sites are permitted to communicate
- The contracted metrics with the VPN customer and between VSPs for
routing table size, routing protocol type, and end-to-end routing
policy.
- The required end-to-end convergence time to avoid the case where
restoration policies, timer values, or fast convergence protocols
(such as BFD), differ between VSPs.
- Inter-AS routing restrictions, where, for example, some VPN
traffic shouldn't be transported across one or more ASes within
an MDE
- Time based restrictions, where, for example, some destinations
cannot be reached during working hours,
- QoS based restrictions, where, for example, traffic should not be
bound for VPN route sources that experience more than a 100 ms
one-way transit delay. Traffic route sources that experience
delay over a certain threshold should not then be announced at
selected VPLs.
Expires November 8, 2006 [Page 28]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
8.5. Security Requirements Gap Analysis
While sections 8. and 8.2. could undoubtedly rely upon the work that
has been conducted by the btns and pki4ipsec (in particular) working
groups, sections 8.3. and 8.4. raise issues that could be partly
covered by the recently-created sidr working group (VPN route
authentication, in particular).
9. Management Requirements
9.1. Performance Metric Statistic Requirements
Agents have stringent usage requirements for an MDE. From this
perspective, VSPs should permit an Agent to have access to
statistical information based upon, (but not necessarily limited
to):
- The volume of traffic that has been conveyed by the entire VPN, a
specific VPN route, forwarded by a specific network element or
over a given period of time that may include a distinction
between incoming and outgoing traffic,
- The volume of VPN traffic that has been dropped by network
elements within a given period of time,
- IPPM (IP Performance Metrics) [RFC-2330] related information that
is relevant to tunnel usage: such information includes one-way
transit delay, inter-packet delay variation etc.,
- Routing state convergence.
9.2. Capital Scaling Requirements
In an MDE, there might be one or more VPLs. At each VPL there may be
one or more interconnected VSP ASes, or a single VSP that uses the
VPL for connectivity between their own ASes.
Traditionally, the interconnection of two VSP ASes has resulted in
the deployment of network element resources that are either
dedicated to those two VSPs, or leased from the VPL operator.
Where there is a need for a VSP to interconnect with multiple other
VSPs, scaling cost efficiency could result if interconnected network
elements could be shared across all VSPs. This multilateral approach
Expires November 8, 2006 [Page 29]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
to VPL design will have increasing benefit as the number of
interconnected VSPs at a VPL increases.
Interconnected network elements at VPLs must therefore be shared
multilaterally.
9.3. Operational Scaling Requirements
Cost of operations is of great concern to a VSP, whether or not VPN
services span their own ASes or those of their VSP partners.
Compared to the capital cost of MDE interconnection at a VPL,
operational cost easily dominates. In an MDE, some, and perhaps all
VSPs, might play a part in delivering services to an individual
customer's VPN.
Within a customer VPN, sites, physical and logical connectivity,
VSPs, VPLs and VPN-specific policies might be variously moved,
added, changed or deleted (MACD) at any time. In fact, different
components of the VPN will, at times, undergo MACD concurrently.
Service MACD lifecycle is part of any customer VPN and will happen
as needed throughout the VPN's service life. As an MDE evolves, with
increasing numbers of VSPs, VPLs and customers, the amount of
service MACD will increase and place a continual and increasing
burden on VSP operators throughout an MDE unless a scalable approach
is taken. Operational scaling criteria could be based upon (but are
not necessarily limited to) the following sections.
9.3.1. Service Independence Requirements
In an MDE, it is inevitable that dependencies will exist between the
services of individual VSPs. For example, a lack of forethought by
the VPL operator by implementing a 'tightly-coupled' VPL
interconnect environment would result in single VSP changes to
topology, bandwidth, routing, QoS, etc., requiring all other VSPs to
modify their definitions of existing services.
Service dependencies amongst VSPs in a MDE must therefore be
minimized.
9.3.2. Minimize Network Integration Requirements
Currently there is no common agreement for how VSPs implement the
interconnection of their VPN networks. This means that each inter-AS
interconnect agreement at a VPL by VSP pairs will be a unique
project, each of which potentially having different design goals and
compromises.
Expires November 8, 2006 [Page 30]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
Each unique inter-AS interconnect agreement will usually take
considerable time and consume highly skilled resources in both
organizations. As the number of VPLs increases, so the load on the
organizations will increase. In an MDE, the required number of
unique inter-AS interconnect agreements could rapidly become
untenable. Unique network inter-AS interconnect agreements amongst
VSP pairs must therefore be minimized.
9.3.3. Third Party Interconnect Requirements
Agents or VSPs require the ability to provide end-to-end services
within an MDE. These Agents or VSPs may however have no desire or be
unable to administer the coordination of business and operational
processes involved in establishing an MDE. In order for an MDE to be
established, the Agent or VSP may therefore require a third party
operator to provide these business and operational process services.
It may be that the third party is another VSP, a systems integrator,
a network integrator or another type of service provider. To achieve
end-to-end service, it is critical that the third party operator is
able to control and coordinate global service business and
operational process policy throughout the MDE.
There is, therefore, a requirement for the business and operational
processes involved in establishing an MDE to be administered by a
third party operator.
9.4. IPVPN Services Demarcation Requirements
9.4.1. Fully Managed Service Demarcation
[RFC-4364] based VPN services may encompass a 'fully managed'
Customer Edge (CE) to CE service with associated SLSs. In an MDE,
this 'fully managed' service is interconnected to other VSP-owned
services via VPLs. For SLS demarcation purposes, the VSP may express
a preference to collocate a dedicated network element at each VPL.
The VPL collocated network elements will, from an operational
perspective function identically to a CE. In contrast to a standard
CE however, each VPL collocated network element will usually support
more than a single VPN across one or more customers and/or VSPs.
From a scalability perspective, this is particularly advantageous
for the VSP when interconnecting multiple VPN services at each VPL
on behalf of one or more Agents. The SLS offered by the VSP to each
Agent partner will in addition to CE-to-CE connectivity, include
connectivity from each CE to one or more VPL collocated network
elements.
Expires November 8, 2006 [Page 31]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
For contractual and/or technical reasons, the VSP may decide for
example to collocate a network element per Agent, per group of
Agents or per VPN. In all cases, consistent, unambiguous service
boundaries for the fully managed service offering are essential.
There is a requirement, therefore for consistent SLS demarcation
points across 'fully managed' VPN service offerings within an MDE.
9.4.2. Mixed Management Service Demarcation
In addition to 'fully managed' services, VSPs also offer VPN
services that allow for a third party such as the VSPs customers to
manage their own CE network elements. IPVPN connectivity of the
customers' CEs via the VSP-owned ASes is done via VSP-owned access
facilities. This type of VPN network outsourcing is known as an
'unbundled' or 'wires-only' service. SLSs are negotiated between the
VSP and their customers that allow the customer managed CE's to
intercommunicate.
In an MDE, when an 'unbundled' service is procured from a VSP by an
Agent, the Agent may want to use the 'unbundled' service to extend
the geographic reach of their VPN footprint by connecting this
service to one or more VPLs. Again, for SLS demarcation purposes,
the VSP may express a preference to collocate a network element at
each VPL.
SLS demarcation points for the selling VSP may then include VPL
collocated network elements that are shared across one or more
Agents and/or VPNs, access facilities linking the Agent-owned CEs,
and common [RFC-4364] based VPN services that span the VSP-owned
AS(es). The Agent must then offer SLSs to their customer that
encompass the VSPs 'unbundled' service and associated SLS(s), as
well as their managed CE offering.
There is a requirement, therefore, for consistent 'unbundled'
service SLS demarcation points across an MDE.
9.5. Remote CE Management Requirement
For contractual and/or technical reasons, Agents or customers have a
requirement to manage Customer Edge (CE) network elements that are
interconnected as part of a [RFC-4364] based VPN service. In an MDE,
the ASes supporting these VPNs may or may not be operated by the
Agent. The Agent will in addition to managing VPN services on behalf
of their customers, usually operate a management network to which
their end customers have restricted or no access. The management
network is used to provide as a minimum IP-based connectivity
Expires November 8, 2006 [Page 32]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
between CEs and the Agent's operations staff, typically located in
one or more operations centers.
In order for an Agent to directly manage CEs connected to ASes that
they do not operate, the Agent will procure 'unbundled' VPN services
from one or more VSP partners. In addition to SLSs that are
negotiated between the Agent and the selling VSP for CE-to-CE
communication, the Agent requires SLSs that encompass the connection
of each CE to the Agent's management network.
There is a requirement, therefore, for an Agent to remotely manage
CE network elements that are directly interconnected through one or
more ASes that are operated by the Agent's VSP partners. The VSP
partner should therefore be capable of supporting one or more common
management network connectivity methods selected by the Agent.
9.6. End-to-End Combined Services Requirement
9.6.1. Combined VPN and Internet Access Requirement
It is common for VSPs to offer combined Internet access and VPN
services via a shared networking infrastructure, e.g. based upon
[RFC-4364]. In an MDE, when an Agent offers this service, it is
sometimes advantageous for the Agent if their VSP partners could
support the local 'breakout' of traffic destined for the Internet
within the VSPs own ASes. An alternative to this is for all
customers Internet and VPN traffic to be transported by the Agent's
VSP partners across VPLs to Internet 'breakout' location(s) in other
ASes. These traffic paths are inevitably suboptimal, raising
performance concerns with the Agent's customers. In addition, the
service is potentially expensive to deliver for the Agent, as there
is little or no differentiation between traffic paths carrying
mission-critical VPN traffic and Internet destined best effort
traffic as all traffic will be forwarded by the VSP partner across
one or more VPLs.
There is a requirement, therefore, in an MDE for VSPs to provide
consistent Internet 'breakout' services that are compatible with an
Agents combined Internet access and VPN services. These
compatibility requirements include (but are not limited to):
- Security, Authentication, Intrusion Detection, Virus protection
services etc.
- Consistent QoS policies across VSPs for best effort or better
than best effort Internet-destined traffic.
Expires November 8, 2006 [Page 33]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
9.6.2. Combined IP and non-IP Application Transport Requirement
Some VSPs offer managed services that include the transporting of
non-IP application traffic across a shared networking infrastructure
based on [RFC-4364]. These 'legacy' applications use networking
protocols (for example X.25, SNA and IPX) that typically do not
support an IP network layer header and therefore cannot natively be
transported across VSP operated ASes. The non-IP packets must
therefore be 'tunneled' across VSP ASes by adding IP and MPLS
headers to the packets. Either end of a 'legacy' application
transport tunnel must support configurations that are based on non-
IP application specific configuration parameters for mapping non-IP
network layer application sources to destination tunnel network
element IP addresses. In an MDE, the non-IP transport tunnel could
span one or more VSP-owned ASes. Network elements that originate and
terminate packets that are forwarded across these non-IP tunnels
could therefore be operated by different VSPs.
There is a requirement, therefore, in an MDE for consistent non-IP
application transport tunnels to be supported by participating VSPs
in an MDE. Tunnel transport consistency per non-IP protocol must
take into account amongst others, agreements on MTU sizing, SLS
conformance, vendor proprietary and standardized encapsulation
techniques etc.
9.7. Management Requirements Gap Analysis
The work that needs to be done to address the requirement described
in section 9.1. can rely upon the work conducted by the ippm working
group. Sections 9.2. and 9.3. (as well as sections 9.5. and 9.6. )
rather refer to operational procedures and guidelines which may not
justify an involvement of the IETF.
But section 9.4. (and section 9.4.2. in particular) encourages the
development of the work formerly initialized by the late diffserv
working group, which introduced the notion of SLS. There is
currently no known IETF effort which would aim at specifying a
format for a SLS template, as discussed in [SLS] for example.
Expires November 8, 2006 [Page 34]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
10. Conclusions
This section extracts from the gap analysis sections, the suitable
actions that are to be conducted for the delivery of BGP/MPLS-based
[RFC-4364] VPN services across multiple administrative domains.
Exhaustive inventories of the set of VSP-specific elementary
components (interfaces, network elements) will be used for deploying
an end-to-end multi-provider VPN topology. This information may be
(partly) stored and maintained in the Management Information Base
described by [RFC-4382]. Nevertheless, the global, service-wide
dimension of the end-to-end topology justifies the specification of
a VPN service model, e.g. based upon [IYER].
- Reliably populating network elements with routing (policy-
specific) configuration information is the base building block
for providing VPN services across multiple VSPs. This information
will be used by the network elements to enforce the corresponding
routing policies. Several candidate working groups could be
solicited to investigate the corresponding (protocol-specific)
issues. This requirement advocates the specification and the
instantiation of a VPN service model including the description,
storage and maintenance of routing configuration information.
Such work could be the primary focus of a newly dedicated effort.
- QoS policy must be consistently enforced by the participating VSP
providers for the delivery and the operation of a given VPN
service. QoS policy information exchanges between VSP providers
require a specific protocol. Several candidate protocols to
exchange such information between VSPs have to be investigated.
This investigation should lead to specific extensions to these
protocols or initiation of a dedicated QoS information exchange
protocol. The corresponding configuration information to be used
by the network elements to enforce QoS policies could benefit
from the work conducted by the netconf WG. This information may
be complemented by QoS routing information.
To support QoS meaningfully across multiple VSPs a consistent set of
metrics shall be defined to provide for consistent service classes.
Moreover performance measurement and monitoring techniques shall be
investigated. Work conducted by the ippm WG (OWAMP (One-Way Active
Measurement Protocol, [OWAMP]), and TWAMP (Two-Way Active
Measurement Protocol, [TWAMP]) protocols) should serve a basis of
this investigation. Performance statistics collections can rely upon
the work conducted by the ippm working group. Dedicated effort is
Expires November 8, 2006 [Page 35]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
expected to extended relevant work such as to provide for the
suitable techniques as required for multi-SP environments.
Providing consistent 'unbundled' service demarcation points across
an MDE and consistent demarcation points across 'fully managed' VPN
service offerings within an MDE encourages the introduction and
development of SLS. There is currently no known IETF effort, which
would aim at specifying a format and exchange mechanisms of SLS
templates. This task could become a specific item of a dedicated
effort in operating multi-SP VPNs.
Encryption work that has been conducted by the btns and pki4ipsec
(in particular) working groups fulfill the needs of multi-provider
VPNs. Label spoofing and authentication requirements are partly
covered by the recently-created sidr working group (VPN route
authentication, in particular).
VPN design guidelines and deployment scenarios, could result in the
publication of an applicability statement document by the l3vpn WG.
The following efforts have been identified:
- Specification of a VPN service model including the description,
storage and maintenance of routing policy and QoS policy
configuration information.
- Protocol(s) and/or extension to existing protocols to exchange the
corresponding information between VSP providers.
- Definition of a consistent set of metrics shall be defined to
provide for consistent service classes.
- Performance measurement, statistic collection and monitoring
techniques shall be investigated as extension to the work initiated
by the ippm working group.
- Specification of a format and exchange mechanisms of SLS
templates.
- Extend applicability of the encryption work conducted by the btns
and pki4ipsec working groups and the newly initiated work of the
sidr working group for VPN information authentication.
- Provide VPN design guidelines and deployment scenarios as
extension of the applicability statement document of the l3vpn WG.
Expires November 8, 2006 [Page 36]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
11. Acknowledgements
This document is the combined effort of the co-editors and the
following contributing authors and reviewers: Dimitri Papadimitriou,
James Humphris, Colin Simpson, Matthew Ford, William Copeland, James
Uttaro, Florent Bersani and David Page.
12. References
12.1. Normative References
[RFC-1930] Hawkinson, J., Bates, T., "Guidelines for creation,
selection, and registration of an Autonomous System
(AS)", RFC 1930, March 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2330] Paxson, V., et al., "Framework for IP Performance
Metrics", RFC 2330, May 1998.
[RFC-2475] Blake, S., et al., ''An Architecture for Differentiated
Services'', RFC 2475, December 1998.
[RFC-2676] Apostolopoulos, G., et al., "QoS Routing Mechanisms and
OSPF Exetensions", RFC 2676, August 1999.
[RFC-2865] Rigney, C., et al., "Remote Authentication Dial-In User
Service (RADIUS)", RFC 2865, June 2000.
[RFC-3644] Snir, Y., et al., "Policy Quality of Service (QoS)
Information Model", RFC 3644, November 2003.
[RFC-4026] Andersson, L., Madsen, T., "Provider-Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March
2005.
[RFC-4031] Carugi, M., et al., "Service Requirements for Layer 3
Provider Provisioned Virtual Private Networks (PPVPNs)",
RFC 4031, April 2005.
[RFC-4111] Fang, L., et al., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC
4111, July 2005.
[RFC-4271] Rekhter, Y., Li, T., et al., "A Border Gateway Protocol
4 (BGP-4)", RFC 4271, January 2006.
Expires November 8, 2006 [Page 37]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
[RFC-4301] Kent, S., Seo, K., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC-1918] Rekhter, Y., "Address Allocation for Private Internets",
RFC 1918, February 1996.
[RFC-4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC-4382] Rosen, E., Rekhter, Y., "MPLS/BGP Layer 3 Virtual
Private Networks (VPN) Management Information Base", RFC
4382, February 2006.
12.2. Informative References
[IYER] Iyer, M., Jacquenet, C., Lago, P., Scandariato, R., "IP
VPN Policy Information Model", draft-iyer-ipvpn-
infomodel-01.txt, Work in Progress, july 2001.
[OWAMP] Shalunov, S., et al., "A One-way Active Measurement
Protocol (OWAMP)", draft-ietf-ippm-owdp-16.txt, Work in
Progress, February 2006.
[TWAMP] Babiarz, J., et al., "A Two-way Active Measurement
Protocol (TWAMP)", draft-ietf-ippm-twamp-00.txt, Work in
Progress, February 2006.
[SLS] Goderis, D., et al., "Attributes of a Service Level
Specification (SLS) Template", draft-tequila-sls-03.txt,
Work in Progress, October 2003.
[VPN-VERIFICATION] Behringer, M., et al., "Layer-3 VPN Import/Export
Verification", draft-ietf-l3vpn-vpn-verification-00.txt,
Work in Progress, March 2005.
[RT-CONSTRAIN] Marques, P., et al., "Constrained VPN Route
Distribution", draft-ietf-l3vpn-rt-constrain-02.txt,
Work in Progress, June 2005.
Expires November 8, 2006 [Page 38]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
Editor's Addresses
Jim Guichard
Cisco Systems, Inc
300 Beaver Brook Rd
Boxborough
MA
Email: jguichar@cisco.com
Martin Halstead
Nexagent Ltd
Thames Tower
37-45 Station Road
Reading
Berkshire
UK
RG1 1LX
Email: mhalstead@nexagent.com
Christian Jacquenet
France Telecom
4, rue du Clos Courtel
BP 91226
35512 Cesson-Sevigne Cedex
France
Email: christian.jacquenet@francetelecom.com
13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Expires November 8, 2006 [Page 39]
Internet-Draft draft-halstead-guichard-mavs-requirements-02 May 2006
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Expires November 8, 2006 [Page 40]
