One document matched: draft-andersson-gels-exp-rsvp-te-00.txt
Network Working Group L. Andersson
Internet-Draft A. Gavler
Intended status: Experimental Acreo AB
Expires: July 30, 2007 January 26, 2007
Extenstion to RSVP-TE for GMPLS Controlled Ethernet - An experimental
approach
draft-andersson-gels-exp-rsvp-te-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.
This Internet-Draft will expire on July 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Andersson & Gavler Expires July 30, 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. Suggested Label . . . . . . . . . . . . . . . . . . . . . 8
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 30, 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.
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 30, 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 Ethernet as specified in in IEEE Std
802.1Q. This has been possible since we control the entire network by
a GMPLS control plane and by default set up loop free LSPs. We have
no traffic that results in that flooding or learning is triggered
entering the network. 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 30, 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 answere 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 asa 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 30, 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 30, 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 (33) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 30, 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VID (12) | DA MAC ADDRESS (20/48) |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DA MAC ADDRESS (28/48) |T|M|L|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.1
VLAN, i.e. learning, ageing, broadcast and a Spanning Tree
Protocol (STP) will be turned on.
R = reserved, set to 0 when sending, ignored when received.
3.3. Suggested Label
The suggested label object is optional and carried in the PATH
message. The format of the suggest is identical to the format of the
Generalized Label object.
The information and flags in the Suggested Label 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 0 by the ingress
LSR in a Suggested Label object, and the field SHALL always be
ignored when received.
Andersson & Gavler Expires July 30, 2007 [Page 8]
Internet-Draft A GELS Experiment January 2007
T = type bit, is set to 1 to indicate that both VID and DA MAC
address should be used as the label. If the bit it set to 0 this
indicates that only the VID should be used as label.
M = merge bit, is set to 0 to indicate that merging is not
allowed, and to 1 to indicate that it is allowed.
L = learning bit, is set to 1 to indicate that the GELS control
plane is used to set up a standard IEEE802.1 VLAN. The learning
bit is set to 0 to indicate that an Ethernet LSP is requested.
R = reserved bit, is always set to 0 when sending, and always
ignored when receiving.
Andersson & Gavler Expires July 30, 2007 [Page 9]
Internet-Draft A GELS Experiment January 2007
4. Procedures
When sending a PATH message the ingress LSR need to include a
Suggested Label object. The information in the Suggested Label
object will be used by the egress node to determine the type of
service requested.
If the ingress LSR does not include a Suggested Label 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 it MUST forward the Suggested Label object 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 WILL interpret this a a request
for a merge capable LSP where both the VID and DA MAC Address is used
a the label.
Note: This section may be extended.
Andersson & Gavler Expires July 30, 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 30, 2007 [Page 11]
Internet-Draft A GELS Experiment January 2007
6. IANA Considerations
There are no requests to the IANA herein.
Andersson & Gavler Expires July 30, 2007 [Page 12]
Internet-Draft A GELS Experiment January 2007
7. Acknowledgements
-
Andersson & Gavler Expires July 30, 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.
[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 30, 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 30, 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 30, 2007 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 01:29:01 |