One document matched: draft-andersson-gels-exp-rsvp-te-01.txt
Differences from draft-andersson-gels-exp-rsvp-te-00.txt
Network Working Group L. Andersson
Internet-Draft A. Gavler
Intended status: Experimental Acreo AB
Expires: July 5, 2007 January 2007
Extenstion to RSVP-TE for GMPLS Controlled Ethernet - An experimental
approach
draft-andersson-gels-exp-rsvp-te-01.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.
This Internet-Draft will expire on July 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Andersson & Gavler Expires July 5, 2007 [Page 1]
Internet-Draft A GELS Experiment January 2007
Abstract
This document specifies the extensions to RSVP-TE that Acreo AB has
used in the GMPLS part of testbed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. GMPLS Controlled Ethernet research . . . . . . . . . . . . . . 4
2.1. The Acreo National Broadband Testbed . . . . . . . . . . . 4
2.2. Ethernet Control Plane . . . . . . . . . . . . . . . . . . 4
2.3. The Ethernet data plane . . . . . . . . . . . . . . . . . 4
2.4. Motivation for a GMPLS controlled Ethernet . . . . . . . . 5
2.5. Incremental development . . . . . . . . . . . . . . . . . 5
3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 7
3.1. Information in the Generalized Label Request Object . . . 7
3.2. Label Definition . . . . . . . . . . . . . . . . . . . . . 7
3.3. Extensions to the Session Attribute Object . . . . . . . . 8
3.4. Suggested Label Object . . . . . . . . . . . . . . . . . . 9
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Andersson & Gavler Expires July 5, 2007 [Page 2]
Internet-Draft A GELS Experiment January 2007
1. Introduction
This Internet Draft documents the extensions to RSVP-TE that were
used in the tests of GMPLS Controlled Ethernet (GELS), which were
performed in the Acreo National Broadband Testbed end of 2006 and
early 2007.
In Section 2 we give a short background of the research in the test
bed in general and the GMPLS controlled Ethernet in particular.
Note: The -01 draft has been updated after comments on the gels
mailing list, and does when it is written not exactly match our
implementation.
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 [RFC2119].
Andersson & Gavler Expires July 5, 2007 [Page 3]
Internet-Draft A GELS Experiment January 2007
2. GMPLS Controlled Ethernet research
2.1. The Acreo National Broadband Testbed
The Acreo National Broadband Testbed (ANBT) has been set up a joint
effort by the Swedish government and the Swedish industry. Acreo AB
was chosen to host the test bed, and the task is to initiate research
projects on different aspects of broadband networks. Methods for
control of carrier Ethernet has attracted quite a bit of interest.
GELS test bed is subset of the ABNT and consists of a 6 GMPLS enabled
IP routers and 4 Ethernet Bridges. In some of our tests we've also
used Linux based SW Ethernet Bridges.
2.2. Ethernet Control Plane
The control plane as implemented in the ANBT consists of three
different parts:
o Routing Protocol - OSPF-TE, we are running the OSPF-TE exactly as
implemented by the Dragon project.
o Signaling protocol - RSVP-TE, we have made the extensions to
RSVP-TE, RFC3471 [RFC3471] and RFC3473 [RFC3473] as specified in
Section 3.
o Link Management Protocol - LMP, we have not yet implemented the
LMP protocol.
2.3. The Ethernet data plane
In the test bed we have used the Ethernet data plane as specified in
IEEE Std 802.1Q. This has been made possible since we control the
entire network by a GMPLS control plane and by default set up loop
free LSPs. We have no traffic entering the network that results in
that flooding or learning is triggered. This is clearly an
artificial condition, but it is very well acceptable in a research
network.
To take GELS into production networks is outside the scope of the
current work we've undertaken, our focus is to establish a test bed
e.g. for tests of new control plane extensions, traffic engineering
paradigms and advanced applications. To run a GMPLS control plane
for a production network will quite possibly require 802.1Q S-VLAN
tags as specified in the IEEE Std 802.1ad Provider Bridging amendment
to IEEE Std 802.1Q. and possibly the future IEEE802.1ah standard.
Andersson & Gavler Expires July 5, 2007 [Page 4]
Internet-Draft A GELS Experiment January 2007
2.4. Motivation for a GMPLS controlled Ethernet
The answer to question "Why GELS?" is simple from a research
perspective. Very much of research starts from the question "What
happens if ...?"
In this case the question was "What happens if we make use of an
GMPLS control plane to control an Ethernet network?" The answer to
that question will decide whether we'll continue using GELS a as
configuration tool while setting up tests in our network. Two
tentative results today is that (1) for the application we have it is
working well and saves us time, and (2) that we will look into the
possibility to control every dynamic or configurable technology by
the GMPLS control plane.
In addition to this we also have a number of external parties
interested in GELS.
We have not been the only party active in this area, we have had a
number of communications with e.g. Dave Allan, Don Fedyk, Dimitri
Papadimitriou, Adrian Farrel, Attila Takacs, Deborah Brungard, Jai
Hyung Cho and Nurit Sprecher. They have not reviewed this document,
but nevertheless have had influence on our thinking on the subject.
This is the major reason to share what we've been doing.
We are also in debt to the Dragon project, that gave us a good start
when we could use their open source code as a starting point.
2.5. Incremental development
Our general approach to GELS has been stable over time, we've wanted
to use the possibility to statically configure Ethernet Bridges by
means of a GMPLS signalling protocol and to learn network topology
and traffic engineering information by means of OSPF-TE.
One thing has been changing though; our understanding what the
"Ethernet label" is and how it can be used.
o Our first approach was that it would be possible to define a new
Tag Protocol Identifier (tpid) that should have pointed to
"Ethernet Label" rather than a 802.1Q VLAN tag. Since this idea
involved major changes to the Ethernet data plane, the Ethernet
Standards and existing implementations this idea were quickly
dropped. However we were able to prove that the concept works on
off the shelf equipment.
o Our second approach was to simply use the 802.1Q VLAN tag, but due
to scalability problems (4096 labels per network) we wanted to
Andersson & Gavler Expires July 5, 2007 [Page 5]
Internet-Draft A GELS Experiment January 2007
swap them per link. The IEEE802.1 have made it very clear this
also breaks existing IEEE standards. However, communications from
IEEE802.1 have opened up for a certain type of VID swapping.
There are indication that the idea of VID swapping, which is
accepted at certain types of interface, might be increasingly
accepted in the future.
o At this point a number of ideas started to emerge from a lot of
different sources. Today we are convinced that an Ethernet tag
should be possible to use as an Ethernet label, often in
combination with the destination MAC Address. Further we are
mostly looking to 802.1Q S-VLAN tags as defined in IEEE Std
802.1ad Provider Bridging amendment to IEEE Std 802.1Q. It is
possible that when the IEEE Std 802.1ah is ready the new tag
defined there will be possible to use.
o Our current network works with standard 802.1Q bridges.
Andersson & Gavler Expires July 5, 2007 [Page 6]
Internet-Draft A GELS Experiment January 2007
3. Protocol extensions
Taking a starting point in RFC3471 [RFC3471] and RFC3473 [RFC3473] we
have made the following extensions and adaptations to RSVP-TE.
3.1. Information in the Generalized Label Request Object
The required information to be carried by a PATH message in the Label
Request Object is defined in RFC3471, and the format of the Label
Request Object is defined in RFC3473 as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the purpose of GELS we use the following encoding of the Label
Request Object:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet (2) | L2SC(51) | G-PID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is according to the parameter definitions in RFC3471.
3.2. Label Definition
The format of a Generalized Label object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
Andersson & Gavler Expires July 5, 2007 [Page 7]
Internet-Draft A GELS Experiment January 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We have defined the Ethernet Label object as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| resv | VID (12) | DA MAC ADDRESS (16/48) |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DA MAC ADDRESS (32/48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The four most significant bits of the Label field is not used and
should be set to 0 went sent and ignored when received.
3.3. Extensions to the Session Attribute Object
The Session Attribute Object is optional and carried in the PATH
message.
In RFC3209 [RFC3209] the Session Attribute Object is defined. The
Session Attribute Class is 207. RFC3209 also defines two C_Types,
LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1.
The LSP_TUNNEL_RA C-Type includes all the same fields as the
LSP_TUNNEL C-Type. Additionally it carries resource affinity
information. This document defines a third format LSP_TUNNEL_ETH,
the C-type = 12. The LSP_TUNNEL_ETH C-type carries all the same
fields as the LSP_TUNNEL_RA C-type. Additionally it carries Ethernet
LSP attribute information.
We have defined the LSP_TUNNEL_ETH C-type as follows. The Session
Attribute Class is 207 and the LSP_TUNNEL_ETH, the C-type is 12.
Andersson & Gavler Expires July 5, 2007 [Page 8]
Internet-Draft A GELS Experiment January 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Flags |T|M|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T = type bit, 1 indicates that both VID and DA MAC address is
used, 0 indicates that only VID is used.
M = merge bit, 1 indicates that merging is allowed, 0 indicates
that merging is not allowed.
L = learning bit, if the learning bit is set to 1 this indicates
that GELS control plane is used to set up a standard IEEE802.1Q
VLAN, i.e. learning, ageing, broadcast and a Multiple Spanning
Tree Protocol (MSTP) will be turned on (L=1) or turned of (L=0).
bit 0 to 28 are reserved, and has to be set to 0 when sending and
ignored when received.
3.4. Suggested Label Object
The suggested label object is optional and carried in the PATH
message. The format of the suggest label is identical to the format
of the Generalized Label object.
The information in the Suggested Label in combination with the flags
in the LSP_TUNNEL_ETH C-type is interpreted as follows:
If the ingress node specifies a VID in the suggested label this is
the VID to be used. If the VID field is set to all zeroes, this
is an indication that no VID is specified.
The DA MAC Address field should always be set to all zeroes by the
ingress LSR in a Suggested Label object, and the field SHALL
always be ignored when received.
Andersson & Gavler Expires July 5, 2007 [Page 9]
Internet-Draft A GELS Experiment January 2007
4. Procedures
When sending a PATH message the ingress LSR may include a Suggested
Label object and/or a Session Atribute Object (C-num = 12). The
information in the Suggested Label object and/or Session Attribute
Object will be used by the nodes to determine the type of LSP
requested.
If the ingress LSR does not include a Suggested Label object or a
Serssion Attribute object in the PATH message, the egress LSR or
merge LSR will treat it as if it were a request for an merge capable
LSP with a label consisting of both a VID and a DA MAC address.
When an intermediate LSR receives a PATH message with a Suggested
Label object and/or a Session Attribute objcet it MUST forward these
objects unchanged, unless it is able to merge on to an existing LSP.
The criteria for merging is for further study.
An egress LSR that receives a path message carrying a Label Request
object but no Suggested Label object or any flags in the Session
Attribute object WILL interpret this a a request for a merge capable
LSP where both the VID and DA MAC Address is used as the label.
Note: This section may be extended.
Andersson & Gavler Expires July 5, 2007 [Page 10]
Internet-Draft A GELS Experiment January 2007
5. Security Considerations
This document specify protocol extensions to RSVP-TE that is intended
to be used in research contexts. Security consideration has
therefore been left for further study and it is strongly recommended
not to use these extensions in any network that is part of or
connected to the Internet.
Andersson & Gavler Expires July 5, 2007 [Page 11]
Internet-Draft A GELS Experiment January 2007
6. IANA Considerations
We will ask IANA to allocate C-type 12 for LSP_TUNNEL_ETH under the
Session Attribute Class 207
Andersson & Gavler Expires July 5, 2007 [Page 12]
Internet-Draft A GELS Experiment January 2007
7. Acknowledgements
-
Andersson & Gavler Expires July 5, 2007 [Page 13]
Internet-Draft A GELS Experiment January 2007
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
Andersson & Gavler Expires July 5, 2007 [Page 14]
Internet-Draft A GELS Experiment January 2007
Authors' Addresses
Loa Andersson
Acreo AB
Email: loa@pi.se
Anders Gavler
Acreo AB
Email: anders.gavler@acreo.se
Andersson & Gavler Expires July 5, 2007 [Page 15]
Internet-Draft A GELS Experiment January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Andersson & Gavler Expires July 5, 2007 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 01:18:29 |