Internet DRAFT - draft-augustyn-vmi-m2m-arch
draft-augustyn-vmi-m2m-arch
Network Working Group Waldemar Augustyn
Internet Draft (Nortel Networks)
Document: draft-augustyn-vmi-m2m-arch-00.txt
Category: Informational Tissa Senevirathne
(Force10)
Himanshu Shah
(Tenor Networks)
June 2001
Architecture and Model for L2 many-to-many VMI Networks
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
Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS:
See reference.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
This ID is intended for the PPVPN WG.
Augustyn, et. al. Expires-December 2001 1
draft-augustyn-vmi-m2m-arch-00.txt June 2001
WHY IS IT TARGETED AT THIS WG(s)
PPVPN deals with provider provisioned VPNs. This document describes
an architecture and model of one particular case of such PPVPN. This
case is a subset of Virtual Metropolitan Internetworks (VMI) which,
in turn is considered a case of PPVPN as stated in [2].
JUSTIFICATION
This architecture and model document helps organizing the effort to
solve complex issues surrounding L2, broadcast domain networks, such
as VMI. There are several drafts related to VMI which describe
certain aspects of the solution and which need a common reference
model. There are more draft in-progress that relate to VMI in one
way or another. These, too, need a good reference for proper
evaluation and placement in the overall solution.
1. Abstract
This document describes an architecture and model for an
unrestricted interconnect, "many-to-many", case of Virtual
Metropolitan Internetworks (VMI). This model most closely resembles
LAN operations of L2 services offered by many Providers. It is
intended to facilitate the continuing effort to specify the set of
protocols and capabilities necessary for implementation of provider
provisioned, broadcast domain, L2 networks (VMI)[4]. VMI is a case
of a Provider Provisioned Virtual Private Network (PPVPN)[2].
2. 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 [3].
3. Introduction
The Virtual Metropolitan Internetworks refer to a customerĘs remote
LAN interconnect through service providerĘs network infrastructure.
The framework for VMI [4] describes the requirements and issues that
pertain to building of high speed metro data networks through
providerĘs infrastructure. A particular subset of VMI framework
refers to a many-to-many or full-mesh LAN network topology model
which closely resemble in behavior, management, configuration and
maintenance the ubiquitous Ethernet networks, commonly popular
amongst all customers
Augustyn, et. al. Expires-December 2001 2
draft-augustyn-vmi-m2m-arch-00.txt June 2001
In this document we present a model for the many-to-many case of VMI
network services. This model is the reference for protocols
involved in the implementation. It can also be useful in designing
service capabilities, features, and business operations models. The
model is intended to conform to the L2 NBVPN requirements laid out
in [5]
4. Network Reference Model
As the standardization effort in the area of VMI intensifies, it
becomes necessary to provide a reference model for each services.
This document presents a reference model for many-to-many,
unrestricted interconnect, VMI topology which meet following
characteristics:
o L2 broadcast domain networks
o Many-to-many topology
o Transparent deployment (a.k.a. PE-based)
All devices in the model represent a logical functionality. The
actual implementations may, and frequently do, involve more than one
physical unit. Conversely, combining functionality within a single
device is possible.
4.1. Local Domain VPN Model
The first, most essential, capability is to provide a robust many-
to-many connectivity between sites. A Local Domain VPN model, while
not general, serves this purpose well. In this model, the emphasis
is placed on redundant configurations. A solution must work well
with redundant paths and take full advantage of their existence.
Many known L2 solutions have trouble with multipath connectivity and
multi-home access to customers. This model is intended to be a test
for the fundamentals of proposed solutions.
Figure 1 depicts a typical network scenario. Starting from the
Customer side, there are two most prevalent connectivity styles: a
non-redundant single link access (CE2, CE3), and a redundant multi
home access (CE1). In each case, the first node on the Provider
side plays a special role. These are Provider Edge nodes (PE3, PE4,
PE5). The other nodes on the Provider side do not directly attach
to Customers. These are designated as simply Provider nodes (P1,
P2). The connectivity within a Provider is arranged in a redundant
manner so that a removal of one node or link does not break
connectivity between Customer sites. Of course, the non-redundant
single link to sites CE2 and C3 has a single failure point in PE5.
Augustyn, et. al. Expires-December 2001 3
draft-augustyn-vmi-m2m-arch-00.txt June 2001
........................................
: :
: +-----+ :
: | PE3 | +----+ :
---| |------------| P2 | :
+-----+ / : +-----+ -------| |-- :
| |- : \ / +----+ \ : +-----+
| CE1 | : ------------ / \ ---| CE2 |
| |- : / \ / +-----+ / : +-----+
+-----+ \ : +-----+ +----+ | PE5 |- :
--------| PE4 |----| P1 |-----| |- :
: +-----+ +----+ +-----+ \ : +-----+
: ---| CE3 |
: : +-----+
:......................................:
CE - Customer Edge Node
PE - Provider Edge Node
P - Provider Node
Fig. 1. Local Domain VPN Model
4.2. Service Reference Model
The more general Service Reference Model builds on the Local Domain
VPN by adding other representative elements as shown in Figure 2.
The second essential capability is to give the Providers an orderly
access to the CustomersĘ VMIs for the purpose of supplying optional
value added services. These include L2 services such as bridging
between different VMIs, but most often L3 and higher services such
as DHCP, L3 VPN gateway, etc. One distinctly important case of that
service is the access to the public Internet.
In this model, the provider has opportunity to offer these services
by gaining orderly access to customerĘs VMIs. It does so by
becoming a virtual node on the customerĘs VMI. The connection is
done in a redundant manner. For the customer, the access appears as
a single node on the network, but the infrastructure must use two or
more physical service nodes backing up each other. In Figure 2,
these nodes are represented by a pair PS6 and PS7.
The third essential capability is the ability to create a VMI system
that consists of several, interconnected VPN domains. Figure 2 shows
a pair of Provider Peering nodes (PP8, PP9) serving as interface to
another Local Domain VPN network via their counterparts (PP10,
PP11). The function of these nodes is to make possible extending
connectivity within a VMI to Customer sites connected to another
Domain (CE4). As usual, the nodes are connected to the rest of the
network in a redundant manner.
Augustyn, et. al. Expires-December 2001 4
draft-augustyn-vmi-m2m-arch-00.txt June 2001
The fourth essential capability is the ability operate the service
in a secure manner providing proper separation of customer traffic
and maintaining immunity from malformed or maliciously constructed
packets sent by the customer. One common topological complication
is the creation of back-door connections between sites served by a
providerĘs VMI network. In Figure 2, the link between Customer
sites CE2 and CE4 represents such part of VMI topology that is
beyond control of the Provider. The link may appear and disappear at
any time without any notice to the Provider. To cover a more
general case, the link is shown to span sites belonging to different
ProvidersĘ VMI domains. The solution must be able to deal with these
types of common complications.
: :
: +-----+ +-----+ : +-----+
: |PP10 | |PP11 | ----| CE4 |
: +-----+ +-----+ : +-----+
: | | Peer Domain | | : |
:.........|.|...............|.|........: |
| | | | |
..........|.|...............|.|......... |
: | | | | : |
: +---+ | | : | back
: --|PP8|------ | | : | door
: / +---+ \ +---+ : | link
: / ------------|PP9| : |
: +-----+ / \ +---+ : |
: | PE3 |----- +----+ / : |
---| |------------| P2 |-- : |
+-----+ / : +-----+ -------| |-- : |
| |- : \ / +----+ \ : +-----+
| CE1 | : ------------ / \ ---| CE2 |
| |- : / \ / +-----+ / : +-----+
+-----+ \ : +-----+ +----+ | PE5 |- :
--------| PE4 |----| P1 |-----| |- :
: +-----+ +----+ +-----+ \ : +-----+
: \ / \ / ---| CE3 |
: \ ---- ---- / : +-----+
: \ / \ / :
: +---+ +---+ :
: |PS6| |PS7| :
: +---+ +---+ :
:......................................:
CE - Customer Edge Node
PE - Provider Edge Node
P - Provider Node
PP - Provider Peering Node
PS - Provider Service Access Node
Fig. 2. Service Reference Model
Augustyn, et. al. Expires-December 2001 5
draft-augustyn-vmi-m2m-arch-00.txt June 2001
5. Processing Reference Model
The Service Reference Model designates distinct functionality to the
nodes in the network. Here, each node type is analyzed. The
functionality and order of processing is logical only, there is no
intention to suggest any particular implementation. In many cases,
depending on chosen scope and set of capabilities, the designated
functionality may be combined into a single device, distributed to
several devices, or be null altogether.
5.1. CE Node Processing Model
This model describes a case of transparent deployment of the VMI,
sometimes referred to as PE-based. The CE is only a node on a VMI
network and does not take any part in the operations of the VMI
itself. The CE could be a switch, a router, or even an end station.
The only function designated to the CE, as far as VMI is concerned,
is the control of the demarcation point for the Customer.
v ingress egress ^
| |
+-------+ +-------+
| DMRC | Demarcation Point Control | DMRC |
+-------+ +-------+
| |
+----------> . . . . . . . . . >----------+
Fig. 3. CE Node Processing Model
5.1.1. DMRC. Demarcation Point Control
The DMRC monitors, perhaps tests, the physical connectivity to the
Provider. The details of functionality and implementation are a
local matter.
5.2. PE Node Processing Model
The PE node plays a prominent role in the implementation of many-to-
many transparent VMI networks. This is the node a customer has
direct connectivity to, hence there is always at least one logical
PE node per each customer site participating in a VMI. Most of the
operational functionality is designated to this node.
Augustyn, et. al. Expires-December 2001 6
draft-augustyn-vmi-m2m-arch-00.txt June 2001
v ingress egress ^
| |
+-------+ +-------+
| DMRC | Demarcation Point Control | DMRC |
+-------+ +-------+
| |
+-------+ +-------+
| PCLSS | Packet Classification | PCLSS |
+-------+ +-------+
| |
+-------+ +-------+
| HCONV | Header Conversion | HCONV |
+-------+ +-------+
| |
+-------+ +-------+
| PDIS | Packet Discrimination | PDIS |
+-------+ +-------+
| |
+-------+ +-------+
| QCTRL | Quality of Service Control | QCTRL |
+-------+ +-------+
| |
+-------+ +-------+
| VFWD | VMI Forwarding | VFWD |
+-------+ +-------+
| |
+-------+ +-------+
| PFWD | Path Forwarding | PFWD |
+-------+ +-------+
| |
+----------> . . . . . . . . . >----------+
Fig. 4. PE Node Processing Model
5.2.1. DMRC. Demarcation Point Control
The DMRC function of PE is similar to the DMRC function of CE, i.e.
making sure connectivity exists. Unlike CE DMRC, the PE DMRC is not
a local matter. The health of the link to the Customer is a
critical item in the Operations Management. It is also a trigger
for VMI join/leave operations. The DMRC can be applicable to a
single Customer or an aggregate of Customers.
The PE DMRC performs the following:
o Customer access monitoring and management
o Customer link monitoring
o L1 loopbacks
DMRC functionality must be agreed upon, implementation is a local
matter.
Augustyn, et. al. Expires-December 2001 7
draft-augustyn-vmi-m2m-arch-00.txt June 2001
5.2.2. PCLSS. Packet Classification
The PE PCLSS deals with allocation of CustomersĘ packets to their
VMIs. There could be several criteria for this classification:
o Interface number
o Layer 2 Classification (MAC address, VLAN tag, p-bits, etc.)
o Layer 3 and above (IP address, port, protocol, TOS byte, etc.)
o Other criteria (packet length, time of day, etc.)
Classification type must be agreed upon, the implementation is a
local matter.
5.2.3. HCONV. Header Conversion
Once a packet is classified as belonging to a particular VMI, the PE
may elect to modify the header. HCONV may include:
o Header extension
o Header compression
o QTAG mapping
The type of HCONV and resulting header formats must be agreed upon.
5.2.4. PDIS. Packet Discrimination
The PDIS function validates packets and determines whether they
should be dropped or processed. It is represented here logically as
a single block even though its actions can take place at more than
one stage of packet processing. There could be several reasons for
dropping packets.
o Duplicate packets
o Error packets
o Validation, Ethernet type, packet length, etc.
o Loop prevention and/or control
o Multilink control (such as 802.1ad, etc.)
o Multi-homing control
o Access List or other policies
PDIS criteria must be agreed upon. In many cases, PDIS is part of a
protocol serving particular objective, such as loop prevention, or
multi-homing. In these cases, the related protocols must be agreed
upon as well.
Augustyn, et. al. Expires-December 2001 8
draft-augustyn-vmi-m2m-arch-00.txt June 2001
5.2.5. QCTRL. Quality Control
The quality control in question refers to promises to the Customers
regarding a particular type of service offered to them. QCTRL is
per VMI, it does not deal directly with the issue of QoS/CoS in the
VMI infrastructure.
QCTRL includes:
o Queue allocation
o Policing
o Shaping
o Packet drop counts
o Committed Service Topology
o SLA parameters
The functionality of QCTRL must be agreed upon, the implementation
is a local matter.
5.2.6. VFWD. VMI Forwarding
The VFWD deals with all issues related to the transport of packets
within a VMI. In this model, there are two forwarding systems. The
VFWD deals only with VMI specifics such as unicast, unknown unicast,
broadcast, multicast, etc. It assumes the existence of tunnels, or
paths, connecting relevant nodes. VFWD is also concerned with
meeting SLA parameters such as bandwidth requirements, priorities,
etc. Several important aspect are addressed:
o Packet transfer method, data plane
o Packet transfer parameters and signaling, control plane
o MAC learning
o MAC caching
o Packet replication for broadcast/multicast
o End point discovery mechanisms
o End point add/delete
o VMI encryption, proxy encryption
In many cases, a related protocol is defined. All details of VFWD,
elected protocols and packet formats must be agreed upon.
5.2.7. PFWD. Path Forwarding
The PFWD deals with the transport capabilities of the entire VMI
infrastructure. The VFWD, discussed earlier, uses paths provided by
PFWD. PFWD is not concerned with meeting any particular SLA
requirements or any VMI specifics. It can be thought of as the
general forwarding infrastructure.
o Packet transfer method, data plane
Augustyn, et. al. Expires-December 2001 9
draft-augustyn-vmi-m2m-arch-00.txt June 2001
o Packet transfer parameters and signaling, control plane
o Infrastructure node discovery
o Infrastructure node add/delete
o Redundancy
o Failure restoration
o Graceful reconfiguration
o Hierarchical VMI inter domain control
o Bandwidth/Resource quota allocation and control
o Path encryption
Here, too, related protocols are defined. All details of PFWD,
elected protocols and packet formats must be agreed upon.
5.3. P Node Processing Model
The P nodes do not have any specific function other than
participating in the PFWD for the VMI infrastructure
v ingress egress ^
| |
+-------+ +-------+
| PFWD | Path Forwarding | PFWD |
+-------+ +-------+
| |
+----------> . . . . . . . . . >----------+
Fig. 5. P Node Processing Model
5.3.1. PFWD. Path Forwarding
Same requirements as 5.2.7.
5.4. PS Processing Model
The Provider Service Access node employs all functionality that is
directly related to providing value added services. In many cases, a
customer VMI will have a logical access point on that node. The
services range can be quite wide:
o Inter-VMI connectivity
o VMI extranet clearinghouse
o Access to public Internet
o Network services (DHCP, NAT, DNS, etc.)
o Security (Public Key management, Certificate server, etc.)
o etc.
The PS node, despite its distinguished function of providing value
added services, plays a similar role to the PE node as far as VMI is
Augustyn, et. al. Expires-December 2001 10
draft-augustyn-vmi-m2m-arch-00.txt June 2001
concerned. For that reason, all requirements under 5.2 are
applicable.
5.5. PP Node Processing Model
The PP nodes facilitates multi domain VMI operations. Its primary
function is in the PFWD area. Additionally, it has demarcation
control responsibility due to the direct connectivity to another VMI
domain.
v ingress egress ^
| |
+-------+ +-------+
| DMRC | Path Demarcation Point Control | DMRC |
+-------+ +-------+
| |
+-------+ +-------+
| PFWD | Path Forwarding | PFWD |
+-------+ +-------+
| |
+----------> . . . . . . . . . . . . >----------+
Fig. 6. PP Node Processing Model
5.5.1. DMRC. Path Demarcation Point Control
The DMRC function of PP is similar to the DMRC function of PE,
making sure connectivity exists. In case of PP DMRC, the Customer
could be another Provider, or perhaps another domain within the same
Provider. In each case, this is an aggregate demarcation point.
The PP DMRC performs the following:
o Peer carrier access monitoring and administration
o Peer carrier link monitoring
o L1 loopbacks
The PP DMRC functionality must be agreed upon, implementation is a
local matter.
5.5.2. PFWD. Path Forwarding
The PFWD is similar to PE PFWD but concentrates on exchange of
necessary information for inter domain transport:
Hierarchical domain control
Reachability information
Peering method, policies
Augustyn, et. al. Expires-December 2001 11
draft-augustyn-vmi-m2m-arch-00.txt June 2001
Typically, related protocols are defined. All details of PFWD,
elected protocols and packet formats must be agreed upon.
6. Security Considerations
This document does not discuss specific security solutions.
Applicable security requirements are presented in [5].
7. References
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2. Carugi, M., et. al., "Service requirements for Provider
Provisioned Virtual Private Networks", Work in Progress, June
2001.
3. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
4. Senevirathne, T., et. al., "Framework For Virtual Metropolitan
Internetworks (VMI)", Work in Progress, February 2001.
5. Senevirathne, T., et. al., "Requirements for Layer 2 Network
Based VPN", Work in Progress, May 2001.
8. Acknowledgments
The on going work at the IETF has greatly influenced the work
presented in this document. Authors wish to extend appreciations to
their respective employers and various other people who volunteered
to review this work and provided comments and feedback.
9. AuthorsĘ Addresses
Waldemar Augustyn
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: 978 288 4993
Email: waldemar@nortelnetworks.com
Tissa Senevirathne
Force10 Networks
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: 408-965-5103
Email: tissa@force10networks.com
Augustyn, et. al. Expires-December 2001 12
draft-augustyn-vmi-m2m-arch-00.txt June 2001
Himanshu Shah
Tenor Networks, Inc.
100 Nagog Park
Acton, MA 01720
Phone 978-264-4900
Email: hshah@tenornetworks.com
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
Augustyn, et. al. Expires-December 2001 13
