One document matched: draft-jiang-l1vpn-dynamic-pit-configuration-00.txt
L1VPN Working Group K. Jiang
Internet-Draft Y. Peng
Intended status: Standards Track D. Wang
Expires: October 23, 2010 UESTC
April 21, 2010
Layer1 vpn dynamic PIT configuration
draft-jiang-l1vpn-dynamic-pit-configuration-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 23, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document describes a mechanism of dynamic Port Information Table
(PIT) configuration for Layer-1 VPNs (L1VPN). This mechanism allows
the customer to configure PIT dynamically via CE-PE signaling.
Jiang, et al. Expires October 23, 2010 [Page 1]
Internet-Draft L1vpn dynamic PIT configuration April 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Premise . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PIT configuring architecture . . . . . . . . . . . . . . . . . 3
4.1. Public Control Channel . . . . . . . . . . . . . . . . . . 4
4.2. User network interface address bounding . . . . . . . . . 5
4.3. Customer-Access-Control Architecture . . . . . . . . . . . 5
5. PIT configuration scenarios . . . . . . . . . . . . . . . . . 5
5.1. Initiate a VPN . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Join in an existing VPN . . . . . . . . . . . . . . . . . 7
5.3. Quit from certain VPN . . . . . . . . . . . . . . . . . . 11
5.4. Delete a VPN . . . . . . . . . . . . . . . . . . . . . . . 11
6. User Network Interface (UNI) signaling . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Jiang, et al. Expires October 23, 2010 [Page 2]
Internet-Draft L1vpn dynamic PIT configuration April 2010
1. Introduction
The purpose of this document is to define a dynamic PIT configuration
mechanism for L1VPNs allowing the customer to configure PIT
dynamically. The PIT contains a list of <CPI, PPI> tuples for all
the ports within its L1VPN as outlined in [RFC5251], and controls the
access of each new customer. However, the PIT cannot be configured
via CE-PE signaling directly on account of security [RFC5251]. To
provide the new customer with more flexibility, this document
proposes a mechanism enabling new customers to configure PIT
dynamically via Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions (GMPLS RSVP-TE) Signaling [RFC3473].
2. Terminology
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 [RFC2119].
3. Premise
This document divides the procedure of VPN construction into two
phases:
1. VPN information configuration. It includes assignment of VPN-ID,
PIT configuration, etc, which are configured before establishing
actual LSP between VPN members.
2. Establishing actual LSP. Each VPN member port can establish
actual LSP to another VPN ports arbitrarily after Phase 1.
All the content of this document belongs to the first phase.
4. PIT configuring architecture
To make PIT configuration dynamically by a new customer, a customer-
access-control architecture and an additional control channel between
CE and PE named Public Control Channel (PCC) are REQUIRED in this
document. The public control channel is a special channel dedicated
to transporting PIT configuration relevant message. The customer-
access-control architecture aims to enable existing L1VPN members to
control the access of each new customer.
Jiang, et al. Expires October 23, 2010 [Page 3]
Internet-Draft L1vpn dynamic PIT configuration April 2010
4.1. Public Control Channel
In the context of L1VPN, a CE is connected to a PE via one or more
ports consisting of one or more channels or sub-channels. The PCC
MAY be supplied by these sub-channels or by any IP channel which is
supported by dedicated line or lay2 VPN, lay3 VPN etc.
Once a Customer Edge (CE) is connected to service provider network, a
PCC SHOULD be bound and configured by service provider.
To initiate a new VPN or join in an existing VPN, the new customers
SHOULD submit the corresponding requests to its adjacent PE via this
PCC.
We refer to the CE's address of the PCC as CE Public Control Channel
Address (Public-CE-CC-Addr), and the PE's address as the PE Public
Control Channel Address (Public-CE-CC-Addr) as shown in figure.1.
Public-CE-CC-Addr and Public-CE-CC-Addr are both REQUIRED to be
unique to the involved CE-PE pair.
+.........................................+
+-----.--+ Control plane +--.-----+
| . | | . |
| . |Public-CE-CC-Addr Pulic-PE-CC-Addr| . |
| . |-----------------------------------| . |
| . |CE-CC-Addr PE-CC-Addr | . |
| . |-----------------------------------| . |
| +..|...................................|..+ |
| CE | | PE |
| +..|...................................|..+ |
| . | Data plane | . |
| . | CPI PPI | . |
| . |-----------------------------------| . |
| . | VPN-PPI | . |
| +..|...................................|..+ |
+--------+ +--------+
Figure 1.Address of user network interface
And the CPI, PPI and VPN-PPI are Customer Port Identifier, Provider
Port Identifier and VPN Provider Port Identifier respectively which
are defined in [RFC5251]. The assignment of the PPIs is controlled
solely by the service provider, while assignment of addresses used by
the CPIs and VPN-PPIs is controlled solely by the administrators of
L1VPN. The CPI, PPI, and VPN-PPI WILL be consulted between CE and PE
sequentially for PIT configuration.
Jiang, et al. Expires October 23, 2010 [Page 4]
Internet-Draft L1vpn dynamic PIT configuration April 2010
4.2. User network interface address bounding
When network needs PIT configuration, the user network interface
addresses WILL be consulted between CE and PE sequentially. The VPN
control channel (CE-CC-Addr and PE-CC-Addr) WILL be determined
through public control channel, And the data plane channel (CPI,PPI
and VPN-PPI) WILL be bound through its VPN control channel. Once
these addresses are fixed, the PIT configuration is finished.
4.3. Customer-Access-Control Architecture
This architecture is to release the service provider from traditional
complicated VPN access control for each new customer and SHOULD be
deployed in customer network without service provider involved.
Each PE not only maintains PIT information for all L1VPN associated
with it, but also maintains the access control information for all
L1VPN. The access information SHOULD contain four items at least as
follows:
1. VPN-ID. It is a virtual VPN identifier assigned by service
provider when a customer initiates a VPN. It is to allow any new
customer to join in it so long as this customer gets the
permission of the customer-access-control. And the VPN-ID is
REQUIRED to be unique in service provider network.
2. Access-tactic. It is an item to identify the tactic of the
customer-access-control for certain VPN. The service provider
network needs not recognize it.
3. Access point. It is to indicate the access point address of
customer-access-control.
4. PPI of source PE. By means of it, other PEs can locate the
source PE for certain VPN-ID conveniently. (We refer to the VPN
initiator CE as source CE, and its adjacent PE as source PE.)
We refer to the table storing the above information on each PE as
VPN-Access-Table.
5. PIT configuration scenarios
There are four scenarios needing PIT configuration:
1. Initiate a VPN;
2. Join in an existing VPN;
3. Quit from certain VPN;
4. Delete a VPN;
All these scenarios are on the assumption that all the customers have
Jiang, et al. Expires October 23, 2010 [Page 5]
Internet-Draft L1vpn dynamic PIT configuration April 2010
got the permission from management control system of service provider
network.
5.1. Initiate a VPN
To initiate a VPN, a customer SHOULD deploy a customer-access-control
for its own VPN firstly, and then send an initiate-VPN-request to its
adjacent PE from PCC. The content of the request SHOULD contain the
bandwidth, tactic of customer-access-control, and access point as
shown in Figure 2.
+------------------------------------------------+
| bandwidth (1 octets) |
+------------------------------------------------+
| tactic of customer-access-control(1 octets) |
+------------------------------------------------+
| access point (4 octets) |
+------------------------------------------------+
| reserved (4 octets) |
+------------------------------------------------+
Figure 2.The initiate-VPN information
When the service provider receives this request, it WILL check
whether there is enough data plane resource to support the bandwidth
requirement. If there is enough resource, the service provider WILL
assign a VPN-ID for this customer, and send a VPN-ID-announcement to
the customer from PCC as illustrated in Figure 3. Meanwhile, the PIT
configuration SHOULD be finished for this customer. Besides, a VPN-
access-configuration message WILL be advertised to all PEs through
multi-protocol Extensions to BGP [RFC4760].
+------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------+
| reserved (8 octets) |
+------------------------------------------------+
Figure 3.The VPN-ID announcement information
[RFC4760] defines the format of two BGP attributes, MP_REACH_NLRI and
MP_UNREACH_NLRI, which can be used to announce and withdraw the
announcement of reachability information. We introduce a new
subsequent address family identifier, named PIT-Dynamic-
Jiang, et al. Expires October 23, 2010 [Page 6]
Internet-Draft L1vpn dynamic PIT configuration April 2010
configuration-Information (to be assigned by the IANA), and also
multiple Network-Layer-Reachability-Informations (NLRIs) formats for
carrying the PIT relevant message which are distinguished by sub-
type.
And a sub-NLRI format is defined for VPN-access-configuration message
as shown in Figure 4. And its sub-type SHOULD be set to 1. The
VPN-ID, access-tactic, access point, PPI of source PE SHOULD be
carried in it.
+------------------------------------------------+
| sub-type (1 octet) |
+------------------------------------------------+
| Length (1 octet) |
+------------------------------------------------+
| VPN-ID Length (1 octet) |
+------------------------------------------------+
| VPN-ID (variable) |
+------------------------------------------------+
| PPI (length) |
+------------------------------------------------+
| PPI of source PE (variable) |
+------------------------------------------------+
| Access-tactic (1 octets) |
+------------------------------------------------+
| Access-point (4 octets) |
+------------------------------------------------+
Figure 4.Encoding of the VPN-access-configuration
Note that if the value of the Length of the Next Hop field (of the
MP_REACH_NLRI attribute) is 4, then the Next Hop contains an IPv4
address. If this value is 16, then the Next Hop contains an IPv6
address.
Each PE maintains a VPN-Access-Table to keep access-control
information for all L1VPN.
5.2. Join in an existing VPN
To join in an existing VPN, the new customer (called join-customer)
SHOULD send a join-in-request to its adjacent PE (called join-PE)
from PCC. The content of the request at least SHOULD contain the
VPN-ID associated with the existing VPN as shown in Figure 5.
Jiang, et al. Expires October 23, 2010 [Page 7]
Internet-Draft L1vpn dynamic PIT configuration April 2010
+------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------+
| reserved (8 octets) |
+------------------------------------------------+
Figure 5.The join-in request information
When service provider network receives this request, it extracts the
VPN-ID information and search local VPN-Access-Table to find out the
tactic of the customer-access-control associated with this VPN, and
then response to the customer as tactic-announcement shown in Figure
6.
+------------------------------------------------+
| Access-tactic (1 octets) |
+------------------------------------------------+
| reserved (8 octets) |
+------------------------------------------------+
Figure 6.The tactic-announcement information
The customer WILL re-encapsulate a re-access-control-request
according to the special format corresponding to the access-control
tactic, and re-sends to its adjacent PE. The format of this request
is shown in Figure 7.
The apply-reply status SHOULD set to 1 as an access control request,
and set to 0 as an access control reply. The access status is valid
only when this message is an access control reply.
Note that the identity authentication info WILL be transparently
passed by service provider network, and be used by customer-access-
control. Therefore, its content is changed according to the tactic
of the customer-access-control.
+------------------------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------------------------+
| apply-reply status(1bits) | access status(1bit)| reserved(6bits) |
+------------------------------------------------------------------+
| Identity authentication info(50 octets) |
+------------------------------------------------------------------+
Jiang, et al. Expires October 23, 2010 [Page 8]
Internet-Draft L1vpn dynamic PIT configuration April 2010
Figure 7.The re-access-control-request information
When the ingress node (join-PE) receives the re-access-control-
request, it WILL map the re-access-control-request information into a
new sub-NLRI of PIT-Dynamic-configuration-Informationn, called
access-request as shown in Figure 8, and its sub-type SHOULD be set
to 2. And then send the access-request to the egress node (source
PE) through multi-protocol Extensions to BGP [RFC4760].
+----------------------------------------------------+
| sub-type (1 octet) |
+----------------------------------------------------+
| re-access-control request information (59 octets) |
+----------------------------------------------------+
Figure 8.Encoding of the access-request
When the egress node (source PE) receives this access-request, it
WILL search local VPN-Access-Table to find out the access point of
the customer-access-control associated with this VPN. And the re-
access-control request information of the access-request WILL be
extracted and mapped into remote-access-request whose format is
identical to the re-access-control request shown in figure 7. and
then the remote-access-request WILL be sent to the access point from
VPN control channel.
When the customer-access-control finishes the identity authentication
for the new customer, it WILL initiate an access-control-reply
message as shown in figure 9, and reply to the source PE.
The apply-reply status SHOULD be set to 0 as an access-control-reply.
And if the customer-access-control approves this new customer, the
access status value SHOULD be set to 1; otherwise, set to 0;
+------------------------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------------------------+
| apply-reply status(1bits) | access status(1bit)| reserved(6bits) |
+------------------------------------------------------------------+
| Identity authentication info(50 octets) |
+------------------------------------------------------------------+
Figure 9.The access-control-reply information
Jiang, et al. Expires October 23, 2010 [Page 9]
Internet-Draft L1vpn dynamic PIT configuration April 2010
When the egress node (source PE) receives this message, it WILL re-
map the access-control-reply information into another new sub-NLRI of
PIT-Dynamic-configuration-Information, called access-reply as shown
in Figure 10, and its sub-type SHOULD be set to 3. And the access-
reply WILL be sent to the join-PE.
+----------------------------------------------------+
| sub-type (1 octet) |
+----------------------------------------------------+
| access-control reply information (59 octets) |
+----------------------------------------------------+
Figure 10.Encoding of the access-reply
When the join-PE receives this reply, it checks the access status
item. If it is a positive reply, the PE WILL configure PIT for this
customer, and send a VPN-port-member-announcement to this customer so
that a port topology can be available to it. Then the customer can
create/delete physical link towards certain VPN member within the
view of the VPN port topology dynamically. The format of this
announcement is shown in Figure 11. Meanwhile, the PIT information
WILL be advertised to the associated PEs through auto-discovery
mechanism [RFC5195].
+------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------+
| CPI num (1 octets) |
+------------------------------------------------+
| CPI AFI (2 octets) |
+------------------------------------------------+
| CPIs |
+------------------------------------------------+
Figure 11.The VPN-port-member-announcement information
CPI num:
Indicating the number of CPI members.
CPI AFI:
Indicating the address family identifier of the CPIs.
Jiang, et al. Expires October 23, 2010 [Page 10]
Internet-Draft L1vpn dynamic PIT configuration April 2010
5.3. Quit from certain VPN
To quit from certain VPN, the customer SHOULD send a quit-from-VPN-
request to its adjacent PE from VPN control channel as shown in
Figure 12.
+------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------+
| reserved (8 octets) |
+------------------------------------------------+
Figure 12.The quit-from-VPN request information
The service provider WILL check whether there are VPN physical links
associated with this customer still. If the physical link exists, it
SHOULD be removed compulsively firstly (it is out of scope of this
document). Then the corresponding PIT configuration WILL be deleted
and a quit-from-VPN-reply WILL be send to the customer from public
control channel. Meanwhile, the auto-discovery mechanism [RFC5195]
WILL be triggered. The format of quit-from-VPN-reply is shown in
figure 13. If the reply is an ack, the status item SHOULD be set to
1; otherwise, set to 0.
+------------------------------------------------+
| L1vpn VPN-ID (8 octets) |
+------------------------------------------------+
| status(2bits) | reserved (6 bits) |
+------------------------------------------------+
Figure 13.The quit-from-VPN-reply information
5.4. Delete a VPN
To delete a VPN that initiated by himself, the customer SHOULD send a
delete-VPN request to its adjacent PE from VPN control channel, the
parameter of the request is same to the quit-from-VPN request. When
the PE receives this request, it WILL check whether there are VPN
members or physical links associated with this very VPN still. If
the physical link exists, it SHOULD be removed compulsively and the
members WILL be forced to quit from this VPN firstly. Then the
corresponding PIT configuration WILL be deleted and a delete-VPN-
reply WILL be send to the customer from public control channel.
Meanwhile, auto-discovery mechanism [RFC5195] WILL be triggered. The
Jiang, et al. Expires October 23, 2010 [Page 11]
Internet-Draft L1vpn dynamic PIT configuration April 2010
format of delete-VPN-reply is identical to the quit-from-VPN-reply as
shown in figure13.
6. User Network Interface (UNI) signaling
For the transmission of the PIT relevant message between CE and PE,
we introduce a new object class (to be assigned by the IANA) to GMPLS
RSVP-TE extensions [RFC3473], namely PIT-Dynamic-Configuration
objcet. It MAY be carried in Path message or Resv message. This new
object contains multiple C-Types (to be assigned by the IANA). And
each message described in the above sections WILL be mapped into
unique C-Types of the PIT-Dynamic-Configuration object. These
massages include initiate-VPN-request, VPN-ID-announcement, join-in-
request, tactic-announcement, re-access-control-request, remote-
access-request, access-control-reply, VPN-port-member-announcement,
quit-from-VPN request, quit-from-VPN-reply and delete-VPN-reply.
All signaling procedures are identical to the GMPLS extensions
specified in [RFC3473], except as noted in this document. And the
signaling procedure about the new object is as described in the above
sections.
7. IANA Considerations
This document requires assignment of a new SAFI, called PIT-Dynamic-
configuration-Information (see Section 4). This assignment has to be
done from the Subsequent Address Family Identifier (SAFI) registry
using the Standards Action allocation procedures. And the Class-num
and C-Type of PIT-Dynamic-Configuration object (see Section 5)
require to be assigned.
8. Security Considerations
Since the PIT can be configured by the customer via signaling between
CE and PE, the L1VPN members SHOULD responsible for access control
for each new customer. Thus, much security consideration is
transfered to the mechanism of the customer-access-control.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Jiang, et al. Expires October 23, 2010 [Page 12]
Internet-Draft L1vpn dynamic PIT configuration April 2010
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5251] Fedyk, D., Rekhter, Y., Papadimitriou, D., Rabbat, R., and
L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.
Authors' Addresses
KunJun Jiang
University of Electronic Science and Technology of China
2006 Xiyuan Road Gaoxinxiqu
Chengdu 200240
CN
Phone: +86 13540321287
Email: jiangkunjun2003@163.com
Yunfeng Peng
University of Electronic Science and Technology of China
2006 Xiyuan Road Gaoxinxiqu
Chengdu, 200240
CN
Email: yfpeng@uestc.edu.cn
Jiang, et al. Expires October 23, 2010 [Page 13]
Internet-Draft L1vpn dynamic PIT configuration April 2010
Dong Wang
University of Electronic Science and Technology of China
2006 Xiyuan Road Gaoxinxiqu
Chengdu 200240
CN
Email: dongwang@uestc.edu.cn
Jiang, et al. Expires October 23, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:40:48 |