One document matched: draft-ouldbrahim-ppvpn-vpoxc-02.txt
Differences from draft-ouldbrahim-ppvpn-vpoxc-01.txt
Provider Provisioned VPN Hamid Ould-Brahim
Internet Draft Nortel Networks
Expiration Date: July 2003 Yakov Rekhter
Juniper Networks
Luyuan Fang
AT&T
Marco Carugi
France Telecom
Yong Xue
UUNET/WorldCom
Riad Hartani
Caspian Networks
Dimitri Papadimitrio
Alcatel
December 2002
Provider Provisioned
GMPLS-based Virtual Private Cross-Connect Service
draft-ouldbrahim-ppvpn-vpoxc-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [RFC-2026], except
that the right to produce derivative works is not granted.
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.
Ould-Brahim, Rekhter, et. al 1
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
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.
Abstract
This document describes a GMPLS-based Virtual Private Network
service called GMPLS-based Virtual Private Cross-Connect
(VPOXC). A VPOXC is a provider provisioned VPN service part of
the customer private network but administered and under the
control of the service provider. A VPOXC operates similarly to a
physical optical cross-connect except that it allows a wide
spectrum of port topology such as hub and spoke, full mesh, and
arbitrary topologies. To the VPOXC customer, the service
provider network appears as a virtual private optical cross-
connect where customer sites are attached to. The VPOXC port
topology is defined by the customer, and enforced by the service
provider. Customers can signal any optical connectivity
according to the port topology implemented by the VPOXC. Client
devices operate within the VPOXC space independently from the
service provider network operations.
Sub-IP Summary ID
This ID targets the PPVPN working group as it deals with a
port-based VPN service. This document describes a GMPLS-based
Virtual Private Network service called GMPLS-based Virtual
Private Cross-Connect (VPOXC). A VPOXC is a provider provisioned
VPN service administered and under the control of the service
provider. A VPOXC operates similarly to a physical optical
cross-connect except that it is using shared resources and
implements a wide spectrum of port topology besides just the
full mesh port topology. To the VPOXC customer, the service
provider network appears as a virtual private optical cross-
connect where customer sites are attached to. The VPOXC port
topology is defined by the customer, and enforced by the service
provider. Customers can signal any optical connectivity
according to the topology implemented by the VPOXC. Client
devices operate within the VPOXC space independently from the
service provider network operations.
RELATED DOCUMENTS
Ould-Brahim, et al. July 2003 [Page 2]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
draft-ouldbrahim-ovpn-requirement-01.txt
draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
Fits the PPVPN box.
WHY IS IT TARGETED AT THIS WG
This WG is looking at port based VPN services and solutions.
This work addresses a port-based Optical VPN service.
JUSTIFICATION
VPOXC based Optical VPNs can also be provided using Provider
Provisioned VPN mechanisms. The service described in this draft
fits most of the generic requirements for PPVPN (similarly to
l2vpn or VPLS).
1. Introduction
This document describes a GMPLS-based Virtual Private Network
service called GMPLS-based Virtual Private Cross-Connect
(VPOXC). A VPOXC is a provider provisioned VPN service
administered and under the control of the service provider. A
VPOXC operates similarly to a physical optical cross-connect
except that it is using shared resources and implements a wide
spectrum of port topology besides just the full mesh port
topology (hub and spoke, arbitrary and full mesh are private
port topologies that can be supported within the VPOXC). To the
VPOXC customer, the service provider network appears as a
virtual private optical cross-connect where customer sites are
attached to. The VPOXC port topology is defined by the customer,
and enforced by the service provider. Customers can signal any
optical connectivity according to the topology implemented by
the VPOXC. Client devices operate within the VPOXC space
independently from the service provider network operations.
The bandwidth associated with each VPOXC depends on the access
bandwidth of each CE to the VPOXC and the port topology
implemented within the VPOXC. As sites are added or removed to
the VPOXC, the total VPOXC bandwidth is accordingly adjusted.
Given the fact that VPOXCs are optical virtual private network
services, therefore they are subject to the same requirements
described in [OVPN-REQ].
2. VPOXC Service Model
Ould-Brahim, et al. July 2003 [Page 3]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
A VPOXC customer defines a port topology to be supported by
service provider. Within this port topology, the customer
selects any connectivity topology. The service provider
restricts and constrains port-to-port connectivity according to
the topology implemented within the VPOXC.
A service provider network offering VPOXC services consists of
devices such as Optical Network Element (ONE) which may be
Optical Cross Connects (OXCs), or SONET/SDH Cross Connects. We
partition these devices into P (provider) ONEs and PE (provider
edge) ONEs. The P ONEs are connected only to the ONEs within
the provider's network. The PE ONEs are connected to the ONEs
within the provider network, as well as to the devices outside
of the provider network. We'll refer to such other devices as
Client Edge Devices (CEs). An example of a CE would be a
router, or a SONET/SDH Cross Connect, or an Ethernet switch. To
each CE part of the same VPN the service provider appears a
virtual private optical cross-connect where customer ports are
attached to it.
VPOXC
+-------------------------------+
| +---+ +---+ |
| | P |....| P | |
| +---+ +---+ |
| PE / \ PE |
| +-----+ +-----+ | +--+
| | | | |-|--| |
+--+ | | | | | | |CE|
|CE|--|-+-----+ | |-|--| |
+--+\ | | | | | +--+
\| +-----+ | | |
| | | | | | +--+
|\| | | |-|--|CE|
| +-----+ +-----+ | +--+
| \ / |
| +---+ +---+ |
| | P |....| P | |
| +---+ +---+ |
| |
+-------------------------------+
Figure 1 VPOXC based Optical VPN reference Model
For the purpose of the VPOXC service, the resources used to
connect a CE to a (VPOXC) PE are represented as TE link [CCAMP-
ROUTING]. As such, all the constructs (e.g., link bundling)
applicable to TE links are applicable here as well. For a given
TE link that connects a CE to a (VPOXC) PE the end point of
that link connected to the CE is referred to as "CE port",
while the end point of that link connected to the (VPOXC) PE is
referred to as "VPOXC port".
Ould-Brahim, et al. July 2003 [Page 4]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
The basic unit of the VPOXC service is an optical or TDM
connection between a port on one CE and a port on another CE
through the VPOXC. The TDM connection (also referred to TDM LSP
in the GMPLS context) rules are driven by [GMPLS-SONET-SDH] for
SDH/Sonet interfaces. These rules must be used when
establishing TDM connections from CE-port(s) to CE-port(s) over
the VPOXC. The number of ports depends on the concatenation
capabilities of these interfaces keeping in mind that when
provided, virtual concatenation does not constraint the VPOXC
port capability. If a port on CE has multiplexing capabilities,
the same port could be used to connect to more than one
(remote) CE ports.
Ports within a VPOXC need not have the same characteristics
But only ports with compatible characteristics could be
connected (e.g., GigE port to GigE port , but not GigE port to
OC-48 port). Furthermore, administrative ownership of VPOXC
ports is orthogonal to the VPN membership of these ports
_Ports within a VPOXC could belong to the same (intranet), or
different (extranet) organizations. Association between a CE
with a particular VPOXC is established/maintained by the
Provider's provisioning system and therefore could be changed
only via provider's provisioning system.
A VPOXC port can be moved to another PE port (or even to
another PE) without changing the VPOXC addressing used by the
customer to request optical connectivity.
Addition/Deletion/Changes of the VPOXC port addresses requires
no coordination with the service provider addressing scheme.
Each VPOXC is associated with one or more control channels used
by the CEs to request optical connections. The control channel
is addressed using addresses defined within the private network
addressing space. Note that a control channel can be an IP
tunnel, FR/ATM VCs, etc. Each PE that provides multiple VPOXC
services is going to have multiple control channels, one per
VPOXC.
The VPOXC ports can be identified by either network layer
addresses (e.g., IPv4 addresses), or by a combination of PE ONE
identifier and a port/interface index (e.g., IP unnumbered
interfaces). A VPOXC service assumes that all the CE ports that
are attached to a given VPOXC have identifiers that are
unambiguous within that VPOXC. The service provider should not
assume that these identifiers are unambiguous outside of that
VPOXC. CE ports attaching to the VPOXC can be identified by
either network layer addresses (e.g., IPv4, IPv6, NSAP
addresses), or by a combination of CE identifier and a
port/interface index (e.g., IP unnumbered interfaces).
Ould-Brahim, et al. July 2003 [Page 5]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
The VPOXC addressing, routing, and signaling used by the
Service Provider network offering the service are completely
independent from the addressing, routing, and signaling used by
the VPOXC clients of that network. Moreover, for the purpose of
the VPOXC service, addressing, routing and signaling used by
one VPOXC client, need not be coordinated with any other VPOXC
clients.
To simplify operations and for better scalability and stability
purposes, the VPOXC service can be implemented using mechanisms
by which a given CE that has at least one port associated with
a given VPOXC could learn about all other ports of that VPOXC,
even if these ports are on other PE ONEs, and even if these
other PE ONEs belong to some other service providers.
Furthermore, as a value added service, a service provider may
provide a CE that has at least one port in a given VPOXC with
the information related to all other CE ports of that VPOXC,
including the information about various properties of these
ports.
Given the fact that a VPOXC is part of the customer private
network, VPOXC customer may choose to run private routing
protocol within the VPOXC (for example using both GMPLS
signaling and GMPLS routing at the VPOXC level). Private
routing exchange will be discussed in future revisions of this
draft.
3. Security Considerations
In order to meet privacy requirements, VPOXC addresses should
only be visible within that VPOXC and must not be leaked to
other VPOXCs (OVPNs).
4. References
[OVPN-REQ] Ould-Brahim, H., et al., "Service Requirements for
Optical Virtual Private Networks", draft-ouldbrahim-ovpn
requirement-01.txt, work in progress.
[BGPGMPLS-OVPN] Ould-Brahim H., Rekhter Y., et al., "BGP/GMPLS
Optical VPNs", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-02.txt,
work in progress
[CCAMP-ROUTING] Kompella, K, Rekhter, Y., et al., _Routing
Extensions in Support of Generalized MPLS_, draft-ietf-
ccamp-gmpls-routing-01.txt, work in progress
Ould-Brahim, et al. July 2003 [Page 6]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
[GMPLS-SONET-SDH] Mannie, E., et al., "GMPLS Extensions for
SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh-
02.txt
5. Author's Addresses
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
Email: yakov@juniper.net
Luyuan Fang
AT&T
200 Laurel Avenue
Middletown, NJ 07748
Email: Luyuanfang@att.com
Phone: +1 (732) 420 1920
Marco Carugi
France Telecom R&D
Technopole Anticipa, 2 av. P. Marzin
22307 Lannion
France
Phone : +33 2 96053617
marco.carugi@francetelecom.com
Yong Xue
UUNET/WorldCom
Ashburn, Virginia
(703)-886-5358
yxue@uu.net
Riad Hartani
Caspian Networks
170 Baytech Drive
San Jose, CA 95143
Phone: 408 382 5216
Email: riad@caspiannetworks.com
Ould-Brahim, et al. July 2003 [Page 7]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
Dimitri Papadimitrio
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Ould-Brahim, et al. July 2003 [Page 8]
draft-ouldbrahim-ppvpn-vpoxc-02.txt December 2002
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
Ould-Brahim, et al. July 2003 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 14:55:14 |