Internet DRAFT - draft-li-l1vpn-ds-info-distribution
draft-li-l1vpn-ds-info-distribution
Network Working Group Dan Li
Jianhua Gao
Internet Draft Huawei
Proposed Status: Standards Track
Expires: December 2006 June, 2006
Directory Server based Information Distribution for L1VPN
draft-li-l1vpn-ds-info-distribution-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes a Directory Server based VPN membership
information distribution mechanism for layer-1 VPNs. The mechanism
enables PEs to discover which other PEs have ports attached to CEs
that are members of the same VPN, and allows PEs to discover
attributes of currently configured CE-PE links and their associations
with layer-1 VPNs. This document builds on the Layer One VPN
Framework and provides an auto-discovery mechanism as discussed in
Li Expires December 2006 [Page 1]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
the Layer One VPN Basic Mode document. This mechanism may be applied
to the layer-1 VPN basic mode.
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 [RFC2119].
Table of Contents
1. Introduction................................................2
2. Procedures..................................................3
2.1. Adding new CE to the VPN................................4
2.2. Deleting a CE from the VPN..............................5
2.3. Updating L1VPN information in Directory Server...........5
3. Security Considerations......................................6
4. IANA Considerations.........................................7
5. Acknowledgments.............................................7
6. References..................................................7
6.1. Normative References....................................7
6.2. Informative References..................................7
7. Author's Addresses..........................................8
8. Full Copyright Statement.....................................8
9. Intellectual Property Statement..............................9
1. Introduction
[L1VPN-BM] describes the motivation to discover L1VPN membership and
access information. This information may be discovered through
configuration, by using routing protocols, or through other means.
[L1VPN-BGP] describes a BGP-based L1VPN auto-discovery mechanism, and
[L1VPN-IGP] describes an OSPF-based L1VPN auto-discovery mechanism,
both mechanisms rely on routing protocols, and some extensions to
these protocols are required in order to support L1VPN auto-discovery.
Manual configuration is another option. When we want to add or delete
a VPN membership, the PE can be manually configured with the updated
VPN membership information. In case of a large number of PEs in the
network, it turns out to be a serious manageability issue, because
each time a VPN membership is added or deleted, all the related PEs
need to be informed.
This document describes another way for the VPN membership
information to be exchanged between PEs. This method uses Directory
Li Expires December 2006 [Page 2]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
Server based information distribution for the L1VPN. The Directory
Server is maintained by the service provider, and the L1VPN
information with respect to the CE-PE association and currently
configured CE-PE link attributes is stored in the Directory Server.
The information that needs to be discovered on a PE local port is the
remote CPI and the VPN-PPI. In many cases if LMP is used between the
CE and PE, LMP can exchange this information. The L1VPN information
is registered to the Directory Server by the PE which discovers or is
informed of the CE-PE relationship. On receiving a service request
from a CE, the associated PE can look up the corresponding L1VPN
information from the Directory Server. This mechanism is applicable
to the L1VPN basic mode.
2. Procedures
Figure 1 shows the Directory Server based auto-discovery for L1VPN.
All the CE-PE associations and CE-PE link attribute information is
maintained by the Directory Server. By sending requests to the
Directory Server, the PE knows which PEs belong to the same VPN, and
how to compute a path from one CE to a remote CE - that is, the PE
can find out which remote PE gives access to the remote CE.
Li Expires December 2006 [Page 3]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
+-----------+
| Directory |
+----+ Server +----+
| | PIT | |
| +-----------+ |
|<--- Register & --->|
| Distribution |
PE | | PE
+-----+---+ +---+-----+
+-----+ |+-------+| |+-------+| +-----+
|VPN-A| || VPN-A || || VPN-A || |VPN-A|
| CE1 |--|| PIT || || PIT ||--| CE2 |
+-----+ |+-------+| |+-------+| +-----+
| | | |
+-----+ |+-------+| |+-------+| +-----+
|VPN-B| || VPN-B || -------- || VPN-B || |VPN-B|
| CE1 |--|| PIT ||-( GMPLS )-|| PIT ||--| CE2 |
+-----+ |+-------+| (Backbone ) |+-------+| +-----+
| | --------- | |
+-----+ |+-------+| |+-------+| +-----+
|VPN-C| || VPN-C || || VPN-C || |VPN-C|
| CE1 |--|| PIT || || PIT ||--| CE2 |
+-----+ |+-------+| |+-------+| +-----+
+---------+ +---------+
Figure 1 Directory Server based auto-discovery for L1VPN
2.1. Adding new CE to the VPN
When a new CE needs to be added to the VPN, the CE sends the request
to the attached PE with the customer port identifier (CPI) and which
VPN ID it belongs to, and the PE sends the authentication request to
the Directory Server.
If the CPI and VPN ID are confirmed by the Directory Server based on
the policy, the Provider Port Identifier (PPI) is assigned. The CE-PE
link attributes can also be discovered by LMP or by other mechanism.
The PE SHOULD register the CE-PE association and the CE-PE link
attribute information with the Directory Server, and this information
MAY also need to be distributed by the Directory Server to other PEs
which belong to same VPN.
If the CPI and VPN ID are rejected by the Directory Server based on
the policy, then the CE SHOULD not be added to the VPN.
Li Expires December 2006 [Page 4]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
2.2. Deleting a CE from the VPN
When PE receives a deletion request from the associated CE, the PE
sends the request to the Directory Server. The Directory Server
SHOULD check the authentication based on the policy.
If the request is confirmed, then the corresponding L1VPN information
related to this CE will be deleted, and a confirmation message sent
to the PE to inform it that the request has completed. Meanwhile, the
Directory Server MAY also send an update messages to all PEs of the
same VPN to update the L1VPN information to reflect the deletion of
the CE.
If the request is rejected, an error message will be returned to the
CE through the PE.
2.3. Updating L1VPN information in the Directory
The L1VPN information stored in the Directory MAY be manually updated
by the service provider. In this case, all the PEs SHOULD be informed
by Directory Server with the updated L1VPN information. The L1VPN
information stored in each PE SHOULD be synchronized with that stored
in the Directory Server.
2.4. Pull or Push model
The Directory MAY be implemented as a centralized directory, in which
case each PE SHOULD look up the VPN membership information for each
request from the associated CE by sending a query request to the
Directory Server. This is called the Pull model.
The Directory Server MAY distribute the VPN membership information to
the PEs which belong to the same VPN. In this way, the PE only need
to look up the VPN membership information from its local database for
each request from the associated CE. The Directory is distributed,
and this is called the Push model.
3. Application to Inter-AS L1VPN
This mechanism also can be applied to the inter-AS network scenario,
where one Directory Server MAY be used for the entire network, or
each AS has its own Directory Server.
3.1. Single Directory Server
When there is only one Directory Server that supports the entire
network, the Directory Server doesn't belong to any AS network. The
Li Expires December 2006 [Page 5]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
same procedure as for a single AS network (described in Section 2) is
applied to this scenario.
3.2. Multiple Directory Server
In the case where each AS has its own Directory Server, then the
interactions between these Directory Servers needs to be considered.
The additional procedures for the coordination between these
Directory Servers is out of scope of this document, and for further
study. Such procedures are likely to be heavily dependent on inter-AS
policy.
4. Security Considerations
The solution presented in this document describes how PEs dynamically
register and learn L1VPN specific information from the Directory
Server.
The Directory Server is maintained by the service provider, and the
information stored in the Directory is about CE-PE associations and
the attributes of CE-PE links. This is information specific to the
service provider.
It is the intention of this model that only PEs need access to the
Directory, and other access SHOULD be restricted.
Directory access protocols (such as LDAP [RFC4513]) are designed to
provide full security against false entry into databases (through
authentication), false distribution of data (through authentication
and verification), and illicit access to information (through
authentication and encryption).
A Directory Server implementation in support of L1VPN discovery MUST
use an established Directory access protocol that includes full
security features.
Consideration MUST also be given to Denial of Service attacks where
false information requests are sent to the Directory Server or to PEs
holding the distributed Directory. Again, Directory access protocols
(such as LDAP [RFC4513]) contain such provisions, but it may also be
necessary for PEs and the Directory Server to perform additional
function such as request throttling to ensure good performance in the
face of a Denial of Service attack.
Li Expires December 2006 [Page 6]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
5. IANA Considerations
This document defines no new protocols or extensions and makes no
requests to IANA for registry management.
6. Acknowledgments
We would like to thank Adrian Farrel for his useful comments.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic Mode",
draft-fedyk-l1vpn-basic-mode (work in progress).
7.2. Informative References
[L1VPN-FRMWK] Tomonori Takeda, et al., " Framework and Requirements
for Layer 1 Virtual Private Networks", draft-ietf-l1vpn-
framework (work in progress).
[L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based
Auto-Discovery for L1VPNs ", draft-ietf-l1vpn-bgp-auto-
discovery (work in progress).
[L1VPN-IGP] Igor B., Lou B., "OSPF-based L1VPN Auto-Discovery",
draft-bryskin-l1vpn-ospf-auto-discovery (work in
progress).
[RFC4513] R. Harrison, "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
Li Expires December 2006 [Page 7]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
8. Author's Addresses
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972910
Email: danli@huawei.com
Yongliang Xu
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972908
Email: ylxu@huawei.com
Jianhua Gao
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972902
Email: gjhhit@huawei.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Li Expires December 2006 [Page 8]
Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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".
Li Expires December 2006 [Page 9]
