Network Working Group Tissa Senevirathne(Nortel)
Internet Draft Waldemar Augustyn (Nortel)
Pascal Menezes (TeraBeam)
Category: Informational
July 2001
A Framework for Virtual Metropolitan Internetworks (VMI)
draft-senevirathne-vmi-frame-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
1. Abstract
This document identifies requirements, issues, and solutions for
Virtual Metropolitan Internetworks. Different VMI models are
discussed. The strengths and weakness of each model against customer
requirements are analyzed.
Table of Content
1. Abstract........................................................1
2. Introduction....................................................3
2.1. VMI Taxonomy..................................................3
2.2. Network Service Model for Virtual Metropolitan Internetwork...4
2.3. VPN vs. VMI...................................................4
2.4. VMIS Requirements.............................................5
3. Service Characteristics.........................................6
3.1. Network Models................................................6
3.1.1. Many-to-many network model..................................6
3.1.2. Point-to-multipoint or hub and spoke network model..........6
3.1.3. Point-to-point network model................................7
Seneviratne, et.al, Expires- January 2002 1
draft-senevirathne-vmi-frame-01.txt July 2001
3.2. Transparent Deployment........................................7
3.3. Routable deployment...........................................7
3.4. Demarcation Point.............................................8
3.5. Scaling.......................................................8
3.6. Data Security and Authentication..............................9
3.7. Transport mechanisms in the core.............................10
3.7.1. QoS and Traffic Engineering................................10
3.7.2. Reliability................................................11
3.7.3. Reconfiguration............................................12
3.7.4. Broadcast and Multicast forwarding.........................12
3.7.5. Layer 2 Address Learning...................................13
3.7.6. End point discovery........................................13
3.7.7. Address Transparency.......................................13
3.7.8. Customer Packet immunity...................................13
3.7.9. Geographically Distributed Sites, Long Haul................14
3.8. VMI Services.................................................14
3.8.1. Transparent L2 Networks....................................15
3.8.2. Virtual Service Provisioning...............................15
3.8.3. Class of Service...........................................15
3.8.4. Bandwidth Allocation and Policing..........................15
3.8.5. Packet Loss Reports........................................16
3.8.6. Service Gradation..........................................16
3.8.7. Service Gateway Functions..................................16
3.8.8. Zero Cost Service Access...................................17
3.9. Service Management...........................................17
3.9.1. Infrastructure Configuration...............................17
3.9.2. Operations Management......................................17
3.9.3. Service Instantiation......................................17
3.9.4. Automated Provisioning.....................................18
3.10. Hierarchical Interconnection model..........................18
3.10.1. Transport.................................................19
3.10.2. Layer 2 Address Learning..................................19
3.10.3. Reliability...............................................19
3.10.4. Scalability...............................................19
3.10.5. Administration............................................20
3.10.6. Accounting................................................20
3.10.7. Service Provisioning and end-point discovery..............20
3.10.8. Virtual Service Provisioning..............................20
4. Service Exchange Points........................................20
5. Security Considerations........................................21
6.References......................................................21
7. Acknowledgments................................................21
8. Author's Addresses.............................................21
Senevirathne, et.al. Expires-January 2002 2
draft-senevirathne-vmi-frame-01.txt July 2001
2. Introduction
Over the last several years, the available bandwidth in the core
networks has increased dramatically, at the same time offering price
per Mbyte has gone down. Most businesses today have multi site
office complexes. Some of these organizations are exploring the
opportunity of outsourcing their inter site enterprise network to
Service Providers. With the opportunities in this segment
increasing, Service Providers are building a new class of network
service based on Metropolitan Area Networks. This new class of
services intends to provide a virtual Internetwork for customers who
wish to connect their geographically dispersed sites using public
networks at very high speeds. In this document we define these
networks as Virtual Metropolitan Internetwork or VMI. The service
that provides VMI is defined as Virtual Metropolitan Internetwork
Services, VMIS.
Issues, requirements, architecture and business model of VMI service
are significantly different from that of the better known Virtual
Private Networks (VPN) or traditional Internetworks. This document
intends to provide a framework for VMIS and documents issues,
requirements, architecture and business model when providing VMIS.
In the past, both the service and the business models were mainly
dictated by the network infrastructure installed by the Service
Providers. Here, we envision the opposite relationship. A ProviderÆs
business model and its customer service requirements would derive
the network infrastructure and its capabilities. The architecture of
a ProviderÆs infrastructure consists of a backbone transport
mechanism, network management and accounting, traffic engineering
and QoS capabilities etc. Hence, with a given infrastructure a
Provider may only be able to satisfy some subset of requirements and
business models. In this document we present, different
infrastructure models and identify the types of requirements and
business models that can be satisfied within the architecture.
2.1. VMI Taxonomy
In this section we define Taxonomy and Analogy of Virtual
Metropolitan Internetworkto facilitate considerations of problems at
hand.
o VMI Infrastructure. A collection of VMI Service ProviderÆs
equipment and methods used to implement VMI service. All
VMI networks share a common infrastructure.
o VMI Network. A virtual network service offered by a VMI
Service Provider, as seen by a Customer. Multiple,
mutually exclusive networks exist within the same, shared
infrastructure.
o VMI Service Management. A VMI Service ProviderÆs means
Senevirathne, et.al. Expires-January 2002 3
draft-senevirathne-vmi-frame-01.txt July 2001
of managing operations of VMI networks.
Given the above taxonomy, VMI can be viewed as a stack of disks on a
base or "Tower of Disks". Each of the disks represents a separate
virtual network. The base represents the Infrastructure. The pin in
the middle represents the Service Management.
|
-----------------
| | VMI-2
-----------------
|
|
| <--------- Service Management
|
|
-----------------
| | VMI-1
-----------------
|
---------------------
| | Infrastructure
---------------------
2.2. Network Service Model for Virtual Metropolitan Internetwork
Presently there are several models that are used to provide VMI
Services. Each of these models may suit customers based on their
requirement. Some service providers exclusively support only one
model; such providers may not be able to accommodate some customer
requirement. In this section we summarize possible service models
that different customers may require.
o Full mesh, many-to-many network model
o Partial mesh model
o point-to-multipoint (hub and spoke) model
o point-to-point model
o hierarchical, multi domain model
2.3. VPN vs. VMI
Understanding the key differences between VPN and VMI is important.
This understanding facilitates one to appreciate the problems,
issues, and strength and business model of VMI clearly.
Senevirathne, et.al. Expires-January 2002 4
draft-senevirathne-vmi-frame-01.txt July 2001
o Service. In simple terms, VMI is a service, while VPN is a
technology. A VMI specification is broader than that of a VPN,
covering areas that VPNs typically consider beyond their scope.
o User/Provider Context. VMI recognizes the demarcation between the
User and the Provider and the consequences of asymmetric
responsibilities and expectations. The Provider is the entity that
offers its services to the receiving entity, the User.
o Gateway Functions. VMI networks, similarly to VPNs, are private,
intended for interconnecting sites belonging to the same
administrative entity. Unlike VPNs, however, VMIs define optional
Provider Gateway Functions, which are methods for secure access to
VMI networks for the purpose of supplying additional network
services.
2.4. VMIS Requirements
VMIS requirements derive the service model. VMIS requirements can be
broadly classified into several areas.
o number of sites that required to be connected.
o Required network topology; hub and spoke with all sites connecting
to the data center or fully meshed emulated Local Area Network or
combination.
o Type of connectivity required; Layer 2 or IP routing.
o Traffic engineering and QoS requirements; end-to-end guaranteed
bandwidth.
o Security; traffic separation, payload encryption and
authentication.
o Billing requirements; wholesale models vs. per byte billing.
o Service Level Agreement (SLA); Time of the day bandwidth vs. flat
bandwidth
o Traffic reporting and accounting; statistics, exceptions, faults,
etc.
o Gateway Functions; option for the Provider to offer extra services
on the private VMI networks.
Senevirathne, et.al. Expires-January 2002 5
draft-senevirathne-vmi-frame-01.txt July 2001
3. Service Characteristics
3.1. Network Models
3.1.1. Many-to-many network model
------ -------
Customer 1| | | | Customer 1
--------- | PE A | | PE B |------
Site A | | --- | | Site B
------ | | -------
| \ | | / |
| -----| | ----------- |
| ----|---|-------- |
| | | |
| | | |
-----| Metro Core |-------
| |
----|---|--------
| | |
| Virtual|Internet
--- |
| |
| |
------- |
Customer 1 | | |
-------------- | PE C |--
Site C | |
-------
Simple many-to-many Virtual Metropolitan Internetwork
Many-to-many VMI network model is ideally suited for customers who
want to have multiple sites connected, via a public network, to form
a one single network. In this topology, either they extend their
Local Network as a layer 2 connectivity or may choose to introduce
to create a routed virtual core. Many-to-many Virtual Metropolitan
Internetwork model is particularly useful for the environment where
service offering is to extend the customer's enterprise network
using the shared network. Many-to-many VMI model is by far the most
general model. Using this model, one may construct any of the other
models.
3.1.2. Point-to-multipoint or hub and spoke network model
The point-to-multipoint model is a subset the of many-to-many-point
model. Point-to-multi-point model may be used for services that
requires connectivity to a centralized site from several remote
sites. Such a service is very similar to more traditional frame
relay deployment. Unlike frame relay networks, VMI point-to-
Senevirathne, et.al. Expires-January 2002 6
draft-senevirathne-vmi-frame-01.txt July 2001
multipoint network may provide additional services that are beyond
the capabilities of classical frame relay networks.
3.1.3. Point-to-point network model
The point-to-point network model is the simplest of all VMI network
models. Due to its simplicity, point-to-point model can be used for
a variety of services that could not be provisioned using other
service models. As an example, providing video or voice services
require strict end-to-end timing. Providing such end-to-end timing
using other service models may not be possible. VMI point-to-point
services are classified into two categories:
o The VMI services that require data services, either in packet or
cell form are called Data service VMI (DSVMI).
o The VMI service that require emulation of some characteristics of
a transport media, such as SONET are called, in this document,
Circuit Emulation VMI (CEVMI).
3.2. Transparent Deployment
In the transparent model, customers may consider the VMI as a
virtual and transparent extension to their Local Network. In other
words; all the sites appear as access points in the same Local
Network.
The Transparent point-to-multi-point and many-to-many models are
mainly used by the customers who wish to extend the Local Network
over the VMI without any network layer address translation. Due to
the anatomy of these models, network edge devices that provide
interface between the customer sites may require to implement
specific forwarding policies. In more traditional frame relay
networks; when deploying hub and spoke models; concepts such as
split horizon may be implemented to prevent reflection of broadcast
traffic. However when providing transparent deployment model
customers may wish to have connectivity from remote site to a remote
site. Cost concern customers who do not wish to purchase fully
meshed many-to-many network and yet achieve many-to-many
reachability may also use point-to-multi-point deployment. VMI
service providers who wish to offer transparent deployment model
MUST have forwarding policies defined to properly forward inter-site
traffic. A simple such policy is to treat each virtual connection as
a separate circuit. A more complex forwarding policies may require
to be defined if all the virtual links to be treated like a single
interface and yet achieve inter-site forwarding.
3.3. Routable deployment
Senevirathne, et.al. Expires-January 2002 7
draft-senevirathne-vmi-frame-01.txt July 2001
In the routable model the VMI access points may be considered as
belonging to the same sub-network. Thus VMI edge devices providing
routing functionality. However, customers may wish to maintain their
private address space shielded from the VMI control plane. At the
same time, VMI Service Providers may not wish to maintain customer
address space. As such, VMI infrastructure may require having
technologies that could transport customer's traffic using some
local addressing and transport mechanisms.
3.4. Demarcation Point
The VMI service recognizes the need for proper demarcation between
the administrative entities involved in the service. Each entity
participating in the service must be able to extend its operations
management and monitoring system to guarantee the delivery of its
obligations.
o Customer-Provider. This type of relationship is sometimes referred
to as ôretailö. In this case, the Provider must have the means
for proving with reasonable certainty that the service, as
described in SLA, is provided throughout the Providers network up
to the demarcation points. These demarcation points are typically
devices owned by the provider that directly connect to customerÆs
equipment. In cases of transparent deployment of VMI services,
these devices can be very simple supporting little more than Layer
1 loopbacks. In cases of routed deployment of VMI services, the
devices are considerably more complex. Typically, these are
switches or routers that are Provider owned or managed but reside
on customer premise.
o Provider-Provider. This type of relationship is sometimes referred
to as ôwholesaleö. In this case, too, the essential objective is
to prove with reasonable certainty that the service provided to
another Provider is operational throughout the network up to the
demarcation point.
o Service domain-Service domain. Even within a single organization,
it is useful to define demarcation points between major service
domains. This type of demarcation is similar to Provider-Provider.
3.5. Scaling
It is important that the VMIS architecture is able to support a
large number of customers with each customer having multiple sites
requiring unconstraint connectivity.
Typically, scalable solutions attempt to place per-VMI parameters in
the edge devices while keeping core networks free from the need to
maintain any state or VMI specific data. The basic premise behind
this strategy is that the infrastructure can grow, potentially
Senevirathne, et.al. Expires-January 2002 8
draft-senevirathne-vmi-frame-01.txt July 2001
indefinitely, by adding edge devices with all per-VMI data localized
in these devices.
This strategy works well if the solution can further localize the
per-site data to the devices directly attaching to the customer
site. As an example if an edge device needs to learn MAC addresses
of the nodes participating in a VMI, it is more scalable if the
learning is limited to the MAC addresses originating in the site
directly attached to the device. Otherwise, if that device has to
learn all MAC addresses, including those originating at other sites,
the device may be overwhelmed by some large sites, perhaps connected
via large edge devices.
3.6. Data Security and Authentication
In VMI Services, customer's data is exposed to the shared network at
the Provider side. A VMI service provider might use services from
other upstream providers for global backbone connectivity. Hence,
privacy may be an issue. Traditionally, it has been the
responsibility of the customer to use their own technology, such as
IPSec, to provide privacy, but with VMI service offerings of speeds
in the range of 1Gbps, the performance of CE based solutions becomes
an issues. It is quite attractive if the VMI service provider can
offer encryption and security. It is quite possible, a customer
sharing the infrastructure with the competitors. Hence, it is
required that customers have ability to protect and authenticate
data.
o Simple Traffic Separation. In many situations a simple, virtual
separation of traffic may be sufficient. This style of security,
frequently referred to as Frame-Relay-like, has gained wide
acceptance in the market place. The provider is entrusted with
making sure VMI traffic remains inaccessible to other customers.
The level of security protects against attacks from other
Customers, but not from the Provider itself.
o Advanced Security. For more sensitive applications, more secure
means, involving encryption and authentication techniques, are
necessary. Essentially there are two approaches to solve this. In
the first approach, customers may choose to install on premise
data encryption devices. Here, there needs to be an out of band
management connectivity between encryption devices. In the second
approach Service provider edge devices may themselves provide data
encryption and authentication.
In the case of many-to-many connectivity, Security Association
establishment and Encryption key distribution become more complex.
Security Architecture for many-to-many networks is presented in [2].
It discusses security architecture of common access networks based
on a case study related to VMI.
Senevirathne, et.al. Expires-January 2002 9
draft-senevirathne-vmi-frame-01.txt July 2001
The security solution for point-to-point VMI depends on the type of
VMI service provided. Hence, the security solution provided for
DSVMI may be different from the CEVMI. Within the DSVMI, based on
the payload types different security solution may be needed. As an
example, when transporting IP only payloads one may choose IP Sec
solution whereas when transporting Layer 2 payloads, service
providers may require to provide a security solution that is
protocol agnostic. Regardless, some customers may wish to have an on
premise security solution. Especially, CEVMI customers may use a
front-end scramblers/encryptors.
3.7. Transport mechanisms in the core
There are multiple transport mechanisms capable of providing the
necessary connectivity. Choice of the appropriate transport depends
on the set of requirements that a given Service Provider wants to
address. As an example, a Provider may choose to have a complete
Layer 2 topology with simpler layer 2 protocol to provide redundancy
and reconfiguration. On the other hand, if a Provider chooses to
support the entire set of requirements, he may choose more
sophisticated protocol such as MPLS. In theory, it is possible that
multiple transport mechanisms are supported in the core.
It is possible that a VMI Service Provider enrolls a customer where
all the sites are NOT within the footprint of the provider. This
would be the case if the VMI service provider uses one set of
transport mechanisms (e.g. MPLS) within its footprint and another
(e.g. IP-Sec, GRE, etc.) for service consistency through some public
backbone (Internet). Obviously various usage policies (QoS) would
have to be different based on the available resources.
When providing a CEVMI service, the transport method should be able
to tunnel the circuits over the VMI infrastructure. The transport in
the VMI core should be capable of supporting emulation of Time
Division Multiplexed (TDM) circuits. Generalized MPLS presented in
[], provides a solution based on MPLS. The chosen transport method
should be able to provide required reliability, end-to-end timing,
service provisioning etc., as agreed upon in the SLA.
When providing a DSVMI service, at least the following issues must
be taken into consideration when selecting a Transport Mechanism:
end-to-end QoS, type of payload (Layer 2/ IP), reliability,
reconfiguration.
3.7.1. QoS and Traffic Engineering
Customers may now wish to have the same QoS and Traffic Engineering
characteristics as they do in a locally connected network. Hence,
now the problem is not providing end-to-end QoS service but
providing network wide QoS and traffic engineering. In general, a
Senevirathne, et.al. Expires-January 2002 10
draft-senevirathne-vmi-frame-01.txt July 2001
given flow, whether Layer 2 or 3, is point-to-point in nature. The
broadcast and multicast nature of local networks can be emulated
using set of fully meshed point-to-point networks. This approach
simplifies the problem and reduces the issue to providing required
QoS level per point-to-point link. If all sites are symmetric in QoS
and Traffic Engineering requirements, the management of QoS and
parameters becomes simple. However, in practice, different sites may
have varying Traffic engineering parameters. In such configurations,
it is important that participating nodes have knowledge of the
requirements of the other nodes and impose shaping and policing
appropriately.
Consider the deployment scenario below. When, node A is sourcing
broadcast traffic it is required not to over-subscribe the link
between A-C, which is only 50% incoming rate of ingress port A'.
Hence, it is essential that participating nodes are capable of
performing egress traffic shaping, as required.
B(node)
/ |
5 Mbits/sec / |
/ |
/ |
5 Mbits/sec / |
--------A'-- A(node) | 5 Mbits/sec
\ |
\ |
\ |
2.5 Mbits/sec \ |
\C(node)
The discovery of these parameters can be either via an automatic
process or via manual configuration. It is possible that some of
these information can be piggy backed to routing protocols such as
OSPF and BGP and advertised to other devices, thereby reducing the
management burden. Alternatively, one may have a system wide
management system that would provision the services.
The QoS and Traffic Engineering service in Circuit emulation VMI
(CEVMI) may require satisfying different Traffic Engineering
parameters than Data Service VMI (DSVMI). Exact set of parameters
depends on the Type of circuit emulation service offered and
customer requirements. As an example, if the ATM circuits are
emulated customer may wish to have only UBR service or CBR service.
Another example is a customer who wishes to extend Frame Relay
network over the VMI. When offering Circuit Emulation services,
transport protocol in the VMI core should be capable of satisfying
different requirements of different categories of circuits.
3.7.2. Reliability
Senevirathne, et.al. Expires-January 2002 11
draft-senevirathne-vmi-frame-01.txt July 2001
Different customers may require different levels of reliability. The
reliability is here defined as protection against service
infrastructure failures. The protection against such failures should
be built into the infrastructure and backbone transport protocols.
The protection can be defined in many flavors such as
Primary/Secondary, Fast Reroute. Protection can also have additional
attributes such as time to restore (50 msec) as well. As an example,
MPLS fast reroute and backup path protection may be needed for some
customers who mandate higher level of reliability. The methods for
providing desired level of reliability for Circuit Emulation VMI
(CEVMI) may be different from methods for providing desired level of
reliability for Data Service VMI (DSVMI). When providing certain
Circuit Emulation VMI, providers must maintain timing requirements.
The committed levels of reliability may be included in Service Level
Agreement. Thus, Service Providers are legally bound to satisfy
these requirements. Inability to provide agreed upon reliability
levels may have financial and/or legal ramifications. At the same
time, these levels of protection may be essential for operation of
their applications.
Providing redundancy in point-to-multipoint deployments may be much
simpler than many-to-many deployment model. It is anticipated that
when purchasing a SLA, the redundancy is specified for the entire
VMI service rather than per site basis. Hence provisioning such
redundancy in a many-to-many network may cause serious complexities
and expenses to the VMI service providers. [wa: I merged the
reliability concepts mentioned in this paragraph with the text
above.
3.7.3. Reconfiguration
It is important to provide uninterrupted services to the customers
during maintenance and upgrades. Thus, methods are essential to be
built into the infrastructure for graceful reconfiguration during
maintenance. Unlike, redundancy provided to address required
reliability, the redundancy required during maintenance is temporary
and may be configured manually.
3.7.4. Broadcast and Multicast forwarding
In general, not all links in a network have the same transport layer
characteristics. Broadcast, multicast packets are required to be
replicated to multiple links with different characteristics. When
providing Layer 2 connectivity the Provider Edge devices are
required to replicate unknown unicast packets as well. Hence, the
Provider Edge devices MUST have methods to replicates packets over
different transport layer characteristics.
In cases of asymmetric topologies, such as point-to-multipoint,
broadcast and multicast forwarding issues are different at specific
Senevirathne, et.al. Expires-January 2002 12
draft-senevirathne-vmi-frame-01.txt July 2001
points in the networks. For example,at the remote sites of a hub-
and-spoke network, the forwarding policies are similar to those
applied to point-to-point networks, but at the hub site forwarding
policies becomes more complex based on whether remote-site to-remote
site connectivity is needed and whether transparent deployment model
or routable model is in place. Such forwarding polices may be
include as part of the Service Level Agreement (SLA).
3.7.5. Layer 2 Address Learning
If the transport mechanism used in the core is based on layer 2, it
is possible that the devices in the middle are required to learn a
large number of MAC addresses. In addition, they may be required to
perform forwarding based on different customer contexts. If this is
chosen then the MAC Forwarding data MUST remain unique per VLAN to
eliminate multiple sites having the same MAC address (Decnet, SNA
etc..)
If one chooses to tunnel layer 2 traffic across the core, the
address learning and forwarding decisions should be limited only to
the Provider Edge devices. Thus helping to scale better. Most
devices have a finite number of MAC addresses they can support. A
Denial of Service attack can be easily performed by blasting large
amount of MAC addresses into the network. Hence, PE devices should
have methods to limit the number of MAC addresses learned from a
given port.
3.7.6. End point discovery
There may be the need for the end points of participating sites to
establish connectivity. These end-points may be either manually
configured or learned via some protocol. OSPF Opaque LSA are one
popular protocol extension that is used to learn end points of the
participating devices. [3] Presents how OSPF Opaque LSA may be used
to discover different Layer 2 reachability.
3.7.7. Address Transparency
A customer considers a VMI to be a totally transparent network.
Packets, headers and payload, are transferred unaltered. Broadcast,
and multicast addresses are recognized and treated accordingly. VLAN
tags are preserved, if present.
3.7.8. Customer Packet immunity
VMI services do not rely on the global uniqueness of customersÆ
addresses, such as MAC addresses, or any addresses. Of course, the
addresses must remain consistent within each VMI for useful service.
Senevirathne, et.al. Expires-January 2002 13
draft-senevirathne-vmi-frame-01.txt July 2001
Nevertheless, the ProviderÆs infrastructure must be immune to the
Customer misaddressed, invalid, corrupted, or maliciously altered
packets.
3.7.9. Geographically Distributed Sites, Long Haul
In general, VMIs are intended for connectivity between sites located
within a metropolitan reach. However the notion of metropolitan
reach may not necessarily imply geographic proximity. Geographic
distances may vary significantly, in many cases exceeding the limits
of the underlying technologies used to build the VMI infrastructure.
In these cases, additional technologies may be employed for the sole
purpose of spanning wide geographic distances. These technologies
are called long haul.
3.7.9.1. Native Long Haul
Here, we define Native Long Haul as the ability to extend the
geographic reach while keeping the same, common infrastructure and
preserving the service management of the original local network.
Referring to the analogy of the Tower of Disks, if the base of the
tower and its pin remain the same, the long haul extension is
native. As an example, if the local network is based on optical
technology and if there exists an optical technology based means to
connect the sites that are located outside the local domain, but
comprise the same infrastructure and are managed by the same
operations system, that is considered a native long haul. On the
other hand if the sites are connected using some other technology
(such as frame relay in the otherwise all Ethernet network) then it
is considered a non-native long haul.
3.7.9.2. Non-native long haul
It is possible to extend the geographic reach using non-native long
haul methods. However, these methods must meet the same requirements
applicable to native methods, such as end-to-end traffic
engineering, reliability etc.
Native long haul may not always be best suited for all network
models. For example, a many-to-many connectivity through a native
long haul may not be financially viable. In these cases, a non-
native solution may be a good alternative.
3.8. VMI Services
For each customer a VMI represents a network that is tailored
specifically for the needs of that customer. For a customer, a VMI
Senevirathne, et.al. Expires-January 2002 14
draft-senevirathne-vmi-frame-01.txt July 2001
services are defined by the set of characteristics a supplied VMI
has.
3.8.1. Transparent L2 Networks
A customer may wish to perform his own assignments and
administration of the addressing, including layer VLAN tagging. The
ability to perform such administration by the customers creates a
truly Virtual Enterprise network extension. All the building blocks
in the VMI architecture, including the transport, need to
participate in order to build a VMI service with virtual service
provisioning requirement. A customer's VLAN tag must be able to be
encapsulated in the transport mechanism, to provide transparency.
3.8.2. Virtual Service Provisioning.
A Provider may offer a method for the Customer to modify the
characteristics of its VMI networks in an automated manner. A
typical use would be requesting more bandwidth or reallocating
priorities.
3.8.3. Class of Service
A VMI recognizes a range of traffic categories. The categories have
significance only within a given VMI. The availability and
allocation of different traffic categories is defined by a Service
Level Agreement and enforced by the Providers VMI Infrastructure.
Typically, a VMI distinguishes guaranteed delivery traffic and best
effort traffic. Within each of these two categories, one or more
priorities may be further distinguished. The guaranteed category of
traffic may also allocate particular latency and jitter commitments
to one of its stated priorities.
3.8.4. Bandwidth Allocation and Policing
The amount of traffic bandwidth allowed to flow within a VMI, total
as well as for each traffic category, is determined by a SLA
agreement. The provider implements traffic policing mechanisms to
enforce the SLA.
For the traffic coming into the ProviderÆs network, the maximum
bandwidth limits are enforced. The customer may implement traffic
shaping mechanisms to avoid unnecessary packet drops.
For the traffic leaving the ProviderÆs network, the maximum
bandwidth limits are enforced. The Provider may offer a back-off
signaling mechanism to aide traffic shaping for the source.
Senevirathne, et.al. Expires-January 2002 15
draft-senevirathne-vmi-frame-01.txt July 2001
3.8.5. Packet Loss Reports
A VMI service may provide an integrated packet loss reporting system
for signaling legitimate packet drops. A legitimate packet drop is
defined as a discard of a customerÆs packet for reasons other than
network failure. The typical reasons are:
o Source rate higher than VMI SLA
o Destination VMI SLA below source rate
o Destination flooded by traffic from many sources
o Best effort congestion
Packet drops due to network failures are not reported. A packet
drop due to congestion for a guaranteed traffic is considered a
failure.
3.8.6. Service Gradation
Not all VMI deployments will support all VMI features. If certain
features are not supported by the infrastructure, the related SLAs
would denote these exceptions. For example, it is conceivable that
in certain situation, the infrastructure would not be redundant but
still provide useful, perhaps less expensive, VMI service.
Similarly, guaranteed service may not be offered by many
infrastructures but the remaining best effort service could still be
offered as a VMI service.
It is useful to list major gradation of VMI service capabilities
o High or standard reliability
o Ability to offer guaranteed service
o Limited distance scope or global reach
o Internet gateway function availability
o Service gateway function availability
o Packet drop reporting
o Traffic encryption or simple separation
Conversely, it is useful to list the minimum set of capabilities
o L2 private network service
o Full support for L2 unicast, broadcast and multicast
o Preservation of L2 headers, including VLAN tags if present
o Ingress/Egress bandwidth policing
o Full customer traffic separation
o Full MAC address space independence
3.8.7. Service Gateway Functions
Senevirathne, et.al. Expires-January 2002 16
draft-senevirathne-vmi-frame-01.txt July 2001
A VMI is quintessentially a private network service. Even if a
Providers offers a services for certain customers, it remains a
private network service. VMI allows an orderly access to customersÆ
VMI network for the purpose of supplying value added services. One
important service of that kind is a gateway to the public Internet.
Other services include DHCP, local DNS, NAT, etc.
o Public Internet gateway
o Value added service gateways
3.8.8. Zero Cost Service Access
A VMI service may be offered to the customer without a need for any
devices located on the customer premises. This is called zero cost
service access, the Provider can provision and modify the service
without the need to install or modify any equipment on the customer
premises. A physical connectivity means, e.g. a fiber cable, must
exist.
3.9. Service Management
The service management capabilities and access methods are common to
all devices comprising VMI infrastructure. The operations of the
entire VMI service system relies on the coherency of Service
Management. It is represented by the pin in the Tower of Disks.
3.9.1. Infrastructure Configuration
The infrastructure for VMI services, the base of the Tower of Disks,
is a collection of a wide range of network equipment. Typically, a
combination of SNMP, TL1, and CLI tools are used for setting this
equipment up. Different methods of configuration can be offered by
different equipment vendors.
3.9.2. Operations Management
Once an infrastructure is set up, the VMI services are controlled by
an Operations Management system. This system represents all methods
and protocols that are used to provision, monitor, and maintain VMI
services. The methods and protocols must be common to all equipment
participating in the service.
3.9.3. Service Instantiation
Senevirathne, et.al. Expires-January 2002 17
draft-senevirathne-vmi-frame-01.txt July 2001
It is possible to create several instances of VMI service
infrastructures sharing the same equipment within a network
provider. For example different wavelength can be dedicated to
different VMI service instances in a WDM systems. Similarly, SONET
transport system can be partitioned based on STS-1 frames for
different VMI systems. This capability extends wholesale
opportunities for Providers.
3.9.4. Automated Provisioning
Depending on the deployed transport mechanism, it may be necessary
to perform complex provisioning along the paths taken between the
sites. Manual provisioning may not be feasible. In such situations,
use of automatic discovery and signaling protocols facilitates
network management. The automatic signaling of provisioning must
have the ability to scale across global networks and be supported by
all involved providers. A hierarchical system may simplify the
solution. Additionally, the signaling layer must have visibility
into path creation to enforce any required constraints.
3.10. Hierarchical Interconnection model
In situations where connectivity spans different administrative
domains, or the complexity of the infrastructure warrants
subdivisions, a hierarchical interconnection model is applicable.
Here we assume that there is a remote service provider that has
agreed to participate in VMI services.
^
| to pop(4L)
|
----------
| |
<-------| pop(3L) |---------> to other pop(3L)
----------
/ \
/ \
/ \
/ \
--------- ----------
| | | | to other
<-----| pop(2L) | -------------------- | pop (2L)|----->
--------- ---------- pop (2L)
| UNION | UNION
--------------------------- -------------------------
| | | |
| -------- -------- | | |
| | | | || | |
| | pop(1L)| ----| pop(1L) || | |
| -------- -------- | | |
Senevirathne, et.al. Expires-January 2002 18
draft-senevirathne-vmi-frame-01.txt July 2001
| | | | | |
| --------- --------- | | |
| | Local | | Local | | | |
| | confederate | confederate | |
| | | | | | | |
| -------- --------- | | |
--------------------------- --------------------------
Sample Hierarchical Interconnection model
The above diagram depicts a hierarchical interconnection model. The
local confederates are the more traditional VMI service providers.
The first level POP connects multiple of local confederates.
collection of local confederates that are below a single first level
pop is considered as a "UNION". The Unions are interconnected using
second level POP.
3.10.1. Transport
The transport method outside the confederates should be able to
provide required services. This may include the end to end traffic
engineering, tunneling of non-native data, reliability and
resilience. In order to have a non-fragmented consistent network
service, all devices are required to support common and adequate
transport mechanisms. MPLS appears to be a promising choice for this
environment. However, this document does not limit the selection of
transport methods.
3.10.2. Layer 2 Address Learning
In the hierarchical interconnection model, the device outside the
local confederate should not perform forwarding based on customer
MAC addresses. Instead, when providing layer 2 services, forwarding
should be performed using some other mechanism. In other words,
devices outside the local confederate provide tunneling services.
3.10.3. Reliability
The reliability of the local confederate depends on the chosen VMI
model and SLA. The devices outside the local confederate should be
able to provide required reliability. This may include the equipment
level and transport methods.
3.10.4. Scalability
The network topology outside the local confederate requires to scale
to potentially large amount of inter site transit tunnels and
traffic.
Senevirathne, et.al. Expires-January 2002 19
draft-senevirathne-vmi-frame-01.txt July 2001
3.10.5. Administration
With the type of diversity in the hierarchical interconnection
model, it is possible that the local confederates belong to
different autonomous systems. Hence, the routing, control plane and
discovery should have knowledge of the inter AS nature.
3.10.6. Accounting
There should be a comprehensive accounting system so customers can
be eventually charged properly. Flat service model or bandwidth
wholesale may not work well in the hierarchical network model.
3.10.7. Service Provisioning and end-point discovery
Due to the diversity of end points, system wide network provisioning
may be administratively prohibitive. It may be better if the
provisioning is performed at the end points and control protocol or
signaling method be used to automatically provision the service
requirements. A good example for this is MPLS RSVP-TE and CR-LDP. On
the other hand it is important to discover the endpoints. This may
be achieved either using IGP or some EGP protocol. [3] presents how
end points may be discovered using OPSF opaque LSA. [4] presents how
these discoveries are done across Autonomous Systems using BGP-MP
extensions.
3.10.8. Virtual Service Provisioning
Some customers require a SLA that allows self-provisioning and
administration of the inter site VMI. Virtual Service provisioning
requires that all-participating providers and equipment has
capabilities to support Virtual Provisioning. Supporting such a SLA
in a multi-vendor, multi-owner, geographically dispersed
infrastructure may be a difficult task.
3.11. Service Exchange Points
Service exchange (SXP) or Internet Exchange Point (IXP) is a new
Internet service-provisioning model. IXP is a logical many-to-many
service where participating customers can connect to each other as
if they are connected a to Local Area Network. Customers of IXP are
generally service providers who wish to connect to other service
providers.
Senevirathne, et.al. Expires-January 2002 20
draft-senevirathne-vmi-frame-01.txt July 2001
IXP MUST have capabilities to restrict peering between participants
to a chosen user group. Logically, each close user group (CUG) in
IXP is identical to a Layer 2 NBVPN domain, where each end
participant representing a separate end point.
In theory IXP is Layer 2 NBVPN deployment. However, IXP may have
some variation in the requirements. As an example, IXP may charge
customer or each end-point of the CUG. Where as traditional Layer 2
NBVPN may charge per entire Layer 2 NBVPN service.
5. Security Considerations
This document does not discuss specific security solutions. This
document, however identify and state the security requirements in
Virtual Metropolitan Internetworks.
6.References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Senevirathne, T., and et.al., "Security Architecture for Common
Access Data Networks - A Case Study based on Virtual Metropolitan
Internetwork", Work In Progress, December 2000.
3 Senevirathne, T., and Billinghurst, P., "Distribution of 802.1Q
VLAN information using OSPF Opaque LSA", Work In Progress,
October 2000.
4 Senevirathne, T., and et.al., "Distribution of 802.1Q VLAN
information using BGP-MP extensions", Work in Progress, November
2000.
7. Acknowledgments
The on going work at the IETF and the work presented in the cited
references has greatly influenced the work presented in this
document. Authors also wish to extend appreciations to their
respective employers and various other people who volunteered to
review this work and provided comments and feedback.
8. Author's Addresses
Tissa Senevirathne
Force10 Networks
1440 McCarthy Blvd,
Milpitas, CA 95051
Phone: 408 965 5103
Senevirathne, et.al. Expires-January 2002 21
draft-vmi-frame-01.txt June 2001
Email: tsenevir@hotmail.com
Waldemar Augustyn
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: 978 288 4993
Email: waldemar@nortelnetworks.com
Pascal Menezes
TeraBeam Networks
2300 Seventh Ave
Seattle, WA 98121
Email: Pascal.Menezes@Terabeam.com
Senevirathne, et.al. Expires-December 2001 22
draft-vmi-frame-01.txt June 2001
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Senevirathne, et.al. Expires-December 2001 23