Internet-Draft Roger Lapuh
Network Working Group Dinesh Mohan
Intended status: Informational Richard Mcgovern
Date Created: July 7, 2008 Nortel
Expiration Date: January 7, 2009
Split Multi-link Trunking (SMLT)
draft-lapuh-network-smlt-08
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 in January 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes Split Multi-link Trunking (SMLT) for bridged
and routed networks. SMLT enables topologies with upstream node
redundancy for increased reliability of Layer 2 link aggregation
Lapuh, et. al. Expires: January 2009 [Page 1]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
subnetworks based on [IEEE 802.3ad] and router redundancy based on
VRRP [RFC3768].
SMLT is an improvement over Multi-Link Trunking (MLT), a method of
link aggregation that allows multiple Ethernet links to be aggregated
together, and handled as a single logical trunk. MLT can be realized
via many different link aggregation mechanisms. Several methods of
MLT are in use today; one example is [IEEE 802.3ad].
SMLT is MLT with links of a link-aggregation group connected to ports
on two different devices (e.g. SMLT client and aggregation device).
Unlike MLT, at least one end of a link-aggregated group is dual-homed
to two different SMLT aggregation devices. In many cases those
devices act as bridges (switches) as well as L3 routers (Routing
Switches). These two redundant SMLT aggregation devices can share one
or more VRRP routing instances; for that SMLT-VRRP extends the VRRP
functionality to an active-active router concept, where both SMLT
aggregation device route traffic for a common VRRP-ID, thus load
balancing traffic not only for L2 but also for L3.
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 RFC 2119.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................2
1. Introduction....................................................3
1.1 Rationale for SMLT.............................................3
2. Definitions.....................................................4
3. SMLT Operation..................................................5
3.1 IST Protocol...................................................7
3.2 SMLT and VRRP active-active....................................8
4. Problems Solved.................................................9
4.1 Layer-2 Traffic Load Sharing...................................9
4.2 Layer-3 Traffic Load Sharing...................................9
4.3 SMLT Configuration Protection in Core of the Network...........9
4.4 No single point of failure....................................10
5. Failure Scenarios..............................................11
5.1 Loss of a SMLT Link...........................................11
5.2 Loss of an SMLT aggregation device............................11
5.3 Loss of IST Link..............................................11
5.4 Loss of All IST Links between an SMLT aggregation device Pair.11
6. SMLT In Relation To Other OSI Reference Model Layers...........12
Lapuh, et. al. Expires: January 2009 [Page 2]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
7. Acknowledgments................................................13
7. IANA Considerations............................................13
8. Security Considerations........................................13
9. References.....................................................14
9.1 Normative References..........................................14
9.2 Informative References........................................14
Intellectual Property Statement...................................14
Authors' Addresses................................................15
Full Copyright Statement..........................................15
1. Introduction
When building redundant networks, Multi-Link Trunking (MLT) offers
link redundancy as a protective measure against link failures.
Multi-Link Trunking is a means of providing physical layer
protection against the failure of a single link, while enabling the
use of the bandwidth of all aggregated links (within MLT) in normal
conditions.
Split Multi-Link Trunking (SMLT) is a means of providing an
additional level of protection against failures. SMLT enables node
redundancy by allowing MLT links of link-aggregated groups to be
dual-homed across a pair of aggregating devices, herein referred to
as a pair of SMLT aggregation devices.
Dual-homing can create looped topologies within subnetworks. To
avoid traffic looping in Layer 2 subnetworks, Spanning Tree Protocol
[IEEE 802.1D/w] acts to logically block redundant network paths to a
given traffic flow.
In SMLT networks, dual-homing is not a problem, because loops in
subnetwork topologies are logically blocked. SMLT may be introduced
into existing subnetworks to provide node redundancy without
upgrading already installed equipment. SMLT improves network
bandwidth availability and network resiliency by allowing all
aggregation paths in a dual-homed configuration to be active and
forwarding traffic simultaneously as well as providing very fast
traffic fail-over in the event of a link failure. An SMLT
aggregation device pair uses an Inter-Switch Trunk (IST) between
them to exchange information, so as to appear as a single logical
path aggregation end point to dual-homed devices. IST signaling also
protects against single points of failure (e.g. link outages and
single node failures) by detecting and modifying information about
forwarding data paths in sub-second intervals.
1.1 Rationale for SMLT
Redundancy in mission-critical network topologies is normally
achieved by engineering multiple paths in order to eliminate all
Lapuh, et. al. Expires: January 2009 [Page 3]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
single points of failure. In addition to ensuring that there is no
permanent loss of connectivity because of a single failure, the goal
is recovery from most failures in the sub-second range. Ideally,
because unused capacity is expensive, any additional paths
introduced to achieve redundancy should also be available to carry
traffic during normal conditions.
SMLT is simple to implement and can be introduced transparently into
existing networks. It is interoperable with the majority of existing
wiring closet/CPE/edge devices, and provides for both link and node
redundancy. SMLT supports utilization of link bandwidth across all
of the aggregated links of multi-link trunks.
2. Definitions
Before describing SMLT in detail it is necessary to define the
following terms:
SMLT aggregation device: An SMLT aggregation device is a device that
provides connectivity to one or more "SMLT Clients" (see below for
definition), and is connected in a peering manner with at least one
other SMLT aggregation device using an Inter-Switch Trunk (IST).
SMLT aggregation devices are often utilized for enterprise
networking, but have applications in service provider networks as
well. As such they may be owned by an enterprise, or by a service
provider.
SMLT Client: An SMLT client is a device (e.g. bridge, host, server)
that is typically connected to one or more Local Area Networks
(LANs), and is itself directly connected to one or more SMLT
aggregation devices.
Note: An "SMLT client" is a literary construct for the purposes of
describing the operation of SMLT in this document. In practice, this
does not require the implementation of any SMLT functionality in a
device described as an SMLT client herein. An example of a typical
SMLT client is a link aggregating device which implements MLT or IEEE
802.3ad link aggregation.
SMLT Link: The connection between an SMLT aggregation device and an
SMLT client is an SMLT link.
IST (Inter-Switch Trunk): An IST is an aggregated point-to-point link
that connects two SMLT aggregation devices to each other. An IST is
used by two SMLT aggregation devices to exchange status and control
information with each other, so as "look" like (i.e. to appear to
operate like) a single device to any SMLT client. This enables the
introduction of SMLT into existing networks without requiring
upgrades to equipment already deployed.
MLT (Multi-Link Trunking): MLT is a method of link aggregation that
allows multiple Ethernet links to be aggregated together, and handled
Lapuh, et. al. Expires: January 2009 [Page 4]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
as a single logical trunk. MLT provides physical layer protection
against the failure of any single link and enables the full use of
the combined bandwidth of the multiple links in non-failure mode
conditions. MLT can be realized via many different link aggregation
mechanisms. Several methods of MLT are in use today; one example is
[IEEE 802.3ad].
SMLT (Split Multi-Link Trunking): SMLT is MLT with each link of a
link-aggregation group connecting a pair of ports on two different
devices (e.g. SMLT client and SMLT Aggregation device). Unlike MLT,
at least one end of a link-aggregated group is dual-homed to two
different SMLT aggregation devices.
3. SMLT Operation
Figure 1 illustrates a reference network configuration for SMLT.
The topology consists of the following elements:
. Two peered SMLT aggregation devices, namely E and F
. Four LAN bridges (A, B, C, D) which are SMLT clients because they
home into one or both of the SMLT aggregation devices
. Eight end stations: a1, b1, b2, c1, c2, d1 (all hosts), and e1 and
f1 (which may be hosts, servers or routers)
+-----+ +-----+
e1 -----| E |====| F |------- f1
/+-----+ +-----+
/ / || \ // | \
/ / || \// | \
/ / || /\ | \
/ / || // \ | \
/ / || // \ | \
/ / || // \ | \
2/ / 2||//2 1\|1 \1
+---+/ +---+ +---+ +---+
| A | | B | | C | | D |
+---+ +---+ +---+ +---+
| | | | | |
| | | | | |
a1 b1 b2 c1 c2 d1
Figure 2: Reference Network for SMLT
SMLT clients B and C use dual-homing to connect to both of the SMLT
aggregation devices. B uses a link-aggregated group containing four
links; two of them connect B to E, and the other two connect B to F.
C uses a smaller link-aggregated group with two links; one link
connects C to E, and the other connects C to F.
Lapuh, et. al. Expires: January 2009 [Page 5]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
SMLT client A also uses link-aggregation, but not for dual-homing.
It has a link-aggregation group with two links, and both links are
used to connect A to E.
SMLT client D is single-homed and uses one link to connect with F.
In figure 2, SMLT clients A and D do not benefit from the added
reliability that SMLT provides for dual-homed SMLT clients.
Conversely, A and D are not disadvantaged either, as they are not
required to implement any new functionality to participate in this
SMLT network.
Dual-homed SMLT clients B and C also do not require any new
functionality to be networked using SMLT. SMLT intelligence and
functionality is implemented entirely within the SMLT aggregation
devices. The behavior of the paired SMLT aggregation devices (E and
F) appears identical to the behavior of a single path aggregation
bridge from the perspective of B and C.
The SMLT aggregation devices (E and F) are interconnected using an
Inter-Switch Trunk (IST). The IST is engineered to be reliable and
not be a single point of failure. An IST has three functions:
. To enable E and F to exchange status information about each other,
and to share learned MAC address information.
. To forward flooded packets, packets destined for non-SMLT
connected subnetworks, and packets destined to end stations
reachable via the other SMLT aggregation device (e.g. traffic from
e1 destined for d1).
. To forward traffic to/from dual-homed SMLT clients during failure
conditions (e.g. traffic from a1 to b1 during a failure of the
direct connection from E to B).
SMLT clients B and C can use different methods to assign traffic to
the links within their MLTs as long as the choice of link remains
fixed for a given flow. This ensures that all traffic is delivered
in-sequence between any pair of communicating end stations.
SMLT aggregation devices normally send traffic directly to an SMLT
client, and uses IST bandwidth only for traffic that cannot be
forwarded using a direct link. The examples below explain this in
more detail.
SMLT client A is single-homed to SMLT aggregation device E. All
traffic from a1 destined for any other end station must flow through
E. For example, to reach b1 and/or b2 traffic flows from a1 to A and
then to E. E forwards the traffic directly to B, to reach b1 and/or
b2. Traffic in the reverse direction (i.e. from b1 or b2 destined
for a1) flows from B to E, and then to A for delivery to a1.
Lapuh, et. al. Expires: January 2009 [Page 6]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
Traffic from b1 or b2 destined for c1 or c2 is always forwarded by B
over one of its dual-homed MLT paths to either E or F. No matter
which of E or F receives incoming traffic from B, the traffic is
directly forwarded to C without traversing an IST. This aspect of
SMLT operation tends to minimize traffic flows across ISTs. It also
means that a single IST failure (in scenarios where there is only
one IST) will not cause a traffic interruption for dual-homed SMLT
clients.
Traffic from a1 to d1 and vice-versa is forwarded across an IST
because it is the shortest path between E and F. For this type of
traffic, an IST emulates an MLT link (with no account taken of SMLT)
as far as A and D are concerned.
Traffic from f1 to c1/c2 is sent directly via F to C. Return traffic
from c1/c2 to f1 may traverse an IST if C sends it to E rather than
to F.
3.1 IST Protocol
An IST connecting two SMLT aggregation devices in figure 2 runs a
protocol that allows the messages to be exchanged between E and F as
follows:
. IST Hello
E and F periodically transmit and receive IST Hello messages on IST
ports. (IST ports are ports used for ISTs.) IST Hello messages
accomplish the following:
- They distinguish ISTs from MLTs. Any port sending IST Hello
messages is an IST port.
- They verify continuity and communication across ISTs. Under normal
conditions, every port sending IST Hello messages should expect to
receive incoming IST Hello messages from the other end.
- They help to identify abnormal conditions, by establishing a normal
time interval between incoming IST Hello messages.
. SMLT Status
E and F exchange SMLT status information with each other about SMLT
client links as follows:
- SMLT ID: This is a provisioned value used by E and F to uniquely
identify links to the same SMLT client.
- SMLT Status: This can be either "in-service," meaning that the SMLT
client is reachable (i.e., one or more of the SMLT links to that SMLT
client are operating); or "out-of-service," indicating that the SMLT
client is not reachable. (All links between the SMLT aggregation
device reporting this status and the SMLT client are not operating.)
. Learned or Migrated MAC Addresses
Whenever E or F learns a new MAC address on any of its ports, it
shares this information with its peer. The learned MAC address value
and the port type of the port at which the address was learned is
Lapuh, et. al. Expires: January 2009 [Page 7]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
communicated across an IST. When the address is learned against an
SMLT client port, SMLT ID is also passed.
. MAC Address Aged Out
When the age expires for a MAC address learned against a non-SMLT
port, the SMLT aggregation device deletes the MAC address record and
sends a message to inform its peer of this action, and to trigger the
deletion of that Mac address from the address table of other SMLT
aggregation device.
. SMLT Address Aged Out
When the age expires for a MAC address learned against an SMLT port,
the SMLT aggregation device does not delete the MAC address record.
It marks the address as having expired locally, and sends a message
with this information to its peer. When the peer SMLT aggregation
device receives this message, it marks the address as having expired
remotely, takes no further action until its own MAC address record
expires locally.
. Local Bridge ID
This message is sent by an SMLT aggregation device to notify its peer
of the value of its own Bridge Identifier. This permits each of E and
F to compare their own ID with the others, and to decide which is the
Root Bridge, as well as the values of BPDU parameters used in SMLT.
3.2 SMLT and VRRP active-active
In many cases, SMLT aggregation devices are Layer-3 routing switches
and perform the default gateway functionality for the hosts which
are part of the attached IP subnets. The SMLT aggregation device
pair can therefore share their default gateway routing functionality
with the VRRP protocol [RFC3768]. The VRRP active-standby operation
can be optimized to an active-active concept due to the following
reason:
. Traffic flowing from an SMLT client to an SMLT aggregation device
is always carried on one of the available links of MLT and ends up
at exactly one of the SMLT aggregation devices. For that reason
both SMLT aggregation switches can be enabled as routers for IP
traffic designed to the VRRP destination MAC address. Both SMLT
aggregation devices must be full members of the routing domain and
have routing entries which allow them to reach the IP destination
networks.
The active-active functionality is achieved without changing any
VRRP state machine, but activating the routing function in the
forwarding plane of the VRRP backup system (similar to the VRRP
master).
The above operation allows traffic forwarding in Layer-2 and Layer-3
to be fully redundant, leveraging all available link bandwidth. All
routers forward traffic and thus load share routed traffic.
Lapuh, et. al. Expires: January 2009 [Page 8]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
4. Problems Solved
4.1 Layer-2 Traffic Load Sharing
Load sharing from the SMLT client perspective is achieved by the MLT
path selection algorithm used on the edge SMLT client switch.
Usually this path selection is done on a SRC/DST MAC address basis,
but other techniques can be used.
Load sharing from the SMLT aggregation device perspective is
achieved by sending all traffic destined to an SMLT client directly
across available links and not over the IST trunk. The IST trunk is
normally not used to send/receive traffic to/from an SMLT dual-homed
SMLT client. Traffic received on the IST by an SMLT aggregation
device is not forwarded on SMLT because the other SMLT aggregation
device will have forwarded the traffic, thus eliminating the
possibility of a loop in the network. The only exception to this
rule is if the SMLT links on the peer aggregation device are down,
then traffic received over IST will be forwarded to the
corresponding SMLT client.
4.2 Layer-3 Traffic Load Sharing
With the SMLT VRRP active-active concept, the router redundancy
operation allows forwarding of routed traffic simultaneously on both
SMLT aggregation devices, thus doubling the router forwarding
capacity. It also decreases Layer-3 failover time since the VRRP
standby router already forwards traffic and does not wait for the
VRRP-hello message from the VRRP master device to expire.
4.3 SMLT Configuration Protection in Core of the Network
SMLT is not limited to use in triangle topologies as shown in figure
2. Several combinations of SMLT designs are feasible, including:
. Bridge using link aggregation dual-homed to an SMLT aggregation
device pair (i.e. an SMLT triangle);
. SMLT aggregation device pair multi-homed to a different SMLT
aggregation device pair, allowing up to four bridges to form a
combined aggregation group SMLT (i.e. an SMLT square).
SMLT can also be used within the core of a network. SMLT groups can
be configured in a square or full mesh scenario.
The following illustration depicts an SMLT square with two SMLT
aggregation device pairs (E/F and G/H) facing each other.
Lapuh, et. al. Expires: January 2009 [Page 9]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
+-----+ +-----+
| E |====| F |
+-----+ +-----+
|| |
|| |
|| |
|| |
|| |
|| |
|| |
+---+ +---+
| G |======| H |
+---+ +---+
The following illustration depicts an SMLT full mesh with two SMLT
aggregation device pairs facing each other.
+-----+ +-----+
| E |====| F |
+-----+ +-----+
|| \ / |
|| \/ |
|| /\ |
|| / \ |
|| / \ |
|| / \ |
||/ \|
+---+ +---+
| G |======| H |
+---+ +---+
These configurations are possible because no state information is
passed across MLT links, so that both devices terminating a MLT
believe that the other end is a single bridge. The result is no
logical looping in this network topology. Any of E, F, G, or H or
any of the connecting links between them can fail and the surviving
elements of this network continue to forward traffic without
interruption.
It is also possible to scale SMLT groups to achieve hierarchical
network designs by connecting SMLT groups together. This allows
building redundant loop-free L2 domains without an additional
protocol while still fully using all network links.
4.4 No single point of failure
Any single link or any SMLT aggregation device can fail and recovery
will take place in less than 1 second. Note that this number is
Lapuh, et. al. Expires: January 2009 [Page 10]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
conservative depending on the implementation and link loss detection
mechanisms. See the analysis in section 5 for further details.
5. Failure Scenarios
5.1 Loss of a SMLT Link
When an SMLT client detects a link failure, it sends traffic on
other SMLT link(s) per the normal algorithms of MLT. Detection and
fail-over depends on the speed at which the SMLT client device
detects link failures.
If the link is not the only one between the SMLT client and an SMLT
aggregation device, then the SMLT aggregation device uses standard
MLT detection and re-routing to move traffic to the remaining links.
If the failed link is the only one to an SMLT aggregation device,
then on failure detection the SMLT aggregation device informs the
other SMLT aggregation device of the SMLT link failure. The other
SMLT aggregation device then treats the SMLT link as a regular MLT
trunk. When the link is re-established, both SMLT aggregation
devices detect this, and put the recovered link back into regular
SMLT operation.
5.2 Loss of an SMLT aggregation device
The SMLT client switch detects link failure and sends traffic on the
other SMLT link(s) just as with standard MLT.
The surviving SMLT aggregation device detects the loss of its peer
(via IST events such as "link down" or "IST Hello timeout") and
treats all SMLT trunks as regular MLT trunks. When the peer SMLT
aggregation device returns to service, the operational SMLT
aggregation device detects this (by virtue of the IST becoming
active) and then restores all trunks to regular SMLT operation.
5.3 Loss of IST Link
The SMLT clients do not detect or notice the failure on an IST, so
they continue to operate as usual.
In normal use, there is more than one link in an IST; an IST is
typically an aggregated link itself. Upon the failure of one IST
link, traffic flows over the remaining links in the IST.
5.4 Loss of All IST Links between an SMLT aggregation device Pair
In the event that all links in an IST fail, the SMLT aggregation
devices do not see each other (IST keep alive is lost) and both
assume that their peer is dead. However, for the most part there
Lapuh, et. al. Expires: January 2009 [Page 11]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
are no ill effects in the network if all SMLT clients are dual-homed
to the SMLT aggregation devices.
6. SMLT In Relation To Other OSI Reference Model Layers
SMLT fits into the datalink layer as it is described in the OSI
reference model. The datalink layer is above the physical layer and
below the network layer.
[IEEE 802.3] defines in the datalink layer the MAC layer below the
optional MAC control layer which is again below the optional link
aggregation sublayer. The MAC client is on top of this forming the
interface to the higher layers such as bridge relay entities for
[IEEE 802.1w] Rapid Spanning Tree and similar protocols.
SMLT is now an optional additional sublayer that is above the link
aggregation sublayer and below the MAC client.
+-----------------------------+
| MAC client |
+-----------------------------+
+-----------------------------+
| SMLT (optional) |
+-----------------------------+
+-----------------------------+
| link aggreg. sublayer (opt) |
+-----------------------------+
+-----------------------------+
| MAC control (optional) |
+-----------------------------+
+-----------------------------+
| MAC |
+-----------------------------+
IEEE protocols such as the [IEEE 802.1w] Rapid Spanning Tree
Protocol (RSTP) operate on top of the MAC client. SMLT is
transparent to such protocols.
Link failures will not trigger any STP re-convergence because the
logical link remains intact as long as one SMLT link out of a group
is active.
SMLT as an underlying path aggregation architecture underneath a
RSTP design has following advantages:
Lapuh, et. al. Expires: January 2009 [Page 12]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
. SMLT does not have any blocking links. Therefore all configured
bandwidth is available for traffic forwarding.
. IST protocol of SMLT is used only on a set of two devices, the
aggregation pair. The protocol, therefore, does not have any
inherent delays because the two are directly connected.
. SMLT convergence targets are sub-second in every failure scenario.
There is no root bridge election and therefore long re-election
processes are not an issue.
In IEEE 802.1D (Spanning Tree) network status changes such as "link
down" events are propagated throughout the network using a message
called Topology Change Notification (TCN). Through these messages
all members of the Spanning Tree network are made aware of the
topology change and all bridges begin reducing to a low value their
aging timers for the learned MAC port relationships in order to
ensure network convergence within a reasonable time window. Whenever
MAC address caches are cleared, packet flooding occurs as part of
the re-learning process.
SMLT link failures do not trigger Spanning Tree to generate network-
wide TCN packets as long as one logical link out of an SMLT group is
still active. Therefore flooding due to aging timer changes is
limited to an SMLT aggregation device pair.
7. Acknowledgments
The authors would like to thank Joe Regan, David Head, Wassim Tawbi,
Vasant Sahay, Yili Zhao, and Ed Juskevicius for their contributions
and furthering the content of SMLT.
7. IANA Considerations
This document has no actions for IANA.
8. Security Considerations
This document does not introduce any new security issues. From a
customer point of view, the SMLT looks the same as [IEEE 802.3ad]
link aggregation. From the service provider point of view, no
security issues are expected, since the IST communication occurs
between aggregation devices located inside the same autonomous
service provider network. When the two aggregation devices are
located in two different autonomous networks, there may be some
security issues, e.g. sharing of bridging information. However, it
is not expected that the aggregation devices will be deployed in two
SP networks.
Lapuh, et. al. Expires: January 2009 [Page 13]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
9. References
9.1 Normative References
[802.1Q] "IEEE Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks", IEEE Std 802.1Q-1998.
[802.1w] "IEEE Standard for Local and metropolitan area networks.
Common specifications Part 3: Media Access Control (MAC) Bridges.
Amendment 2: Rapid Reconfiguration", IEEE Std 802.1w-2001.
[802.1D] "Information technology. Telecommunications and information
exchange between systems. Local and metropolitan area networks.
Common specifications. Part 3: Media Access Control (MAC) Bridges",
ANSI/IEEE Std 802.1D-1998.
[802.3] "IEEE Standard for Information technology.
Telecommunications and information exchange between systems. Local
and metropolitan area networks Specific requirements. Part 3: Carrier
sense multiple access with collision detection (CSMA/CD) access
method and physical layer specifications", IEEE Std 802.3-2002.
[RFC3768] "Virtual Router Redundancy Protocol", IETF Standard, April
2004.
9.2 Informative References
None
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
Lapuh, et. al. Expires: January 2009 [Page 14]
Internet-Draft Split Multi-link Trunking (SMLT) Jul 2008
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Authors' Addresses
Roger Lapuh
Nortel
Wilstrasse 11 Building U95
Switzerland 8610
Email: rlapuh@nortel.com
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Richard Mcgovern
Nortel
600 Technology Park
Billerica, MA 01821
Email: rmcgovern@nortel.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.