Internet Engineering Task Force S. Chakravorty
Internet-Draft J. Bush
Expires: January 10, 2009 The MITRE Corporation
J. Bound
NAv6TF
July 9, 2008
IPv6 Label Switching Architecture
draft-chakravorty-6lsa-03
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 January 10, 2009.
Abstract
This specification provides an architectural framework, called IPv6
Label Switching Architecture or 6LSA, for an end-to-end, IP-centric
packet transmission technique that uses the IPv6 packet header Flow
Label to establish IPv6-based label switched paths. The label
switched paths, called 6LSPs, provide application and user specified
routes for efficient transport of packets and as means for quality of
service (QoS) delivery, IPv4 tunneling, VPN and other mechanisms.
Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses,
the architecture may provide potential memory and processing savings,
the latter through significantly reduced address fetches for the low-
Chakravorty, et al. Expires January 10, 2009 [Page 1]
Internet-Draft IPv6 Label Switching Architecture July 2008
powered, handheld devices. The label has two components comprising
Global Label value and Local Label value. The Global Label value
from the source is delivered to the destination unmodified. However,
the intermediate network nodes in 6LSA are allowed to temporarily
replace the Local Label value with a value of local significance.
This enables 6LSA flows to be hop-specific although session-based and
as such a unique QoS delivery technique for bandwidth constrained
media. 6LSA also enhances security since label generation and
assignment algorithms can be modified periodically.
Finally, it must be pointed out that the 6LSA concept of temporary
flow label assignment is applicable to the 6LSA domain only. The
concept is not applicable to domains outside the 6LSA.
Chakravorty, et al. Expires January 10, 2009 [Page 2]
Internet-Draft IPv6 Label Switching Architecture July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Distinguishing Characteristics of 6LSA . . . . . . . . . . . . 7
5. Routing Versus Switching of IP Traffic . . . . . . . . . . . . 8
6. 6LSA Basic Components and Their Attributes . . . . . . . . . . 9
6.1. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Forwarding Equivalence Class (FEC) . . . . . . . . . . . . 9
6.3. Label . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Labeled Packet . . . . . . . . . . . . . . . . . . . . . . 13
6.5. IPv6 Label Switching Router (6LSR) . . . . . . . . . . . . 13
6.6. Lead Packet . . . . . . . . . . . . . . . . . . . . . . . 13
6.7. Switching Table . . . . . . . . . . . . . . . . . . . . . 14
7. Attributes of Label Binding . . . . . . . . . . . . . . . . . 14
8. IPv6 Label Switched Path (6LSP) . . . . . . . . . . . . . . . 15
9. 6LSA Architectural Functionalities . . . . . . . . . . . . . . 15
10. Label Assignment . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Locally Generated Label Model . . . . . . . . . . . . . . 17
10.2. Distributed Label Model . . . . . . . . . . . . . . . . . 18
10.3. Reuse Label Model . . . . . . . . . . . . . . . . . . . . 19
11. Scope and Uniqueness of Labels . . . . . . . . . . . . . . . . 19
12. Label Retention Mode . . . . . . . . . . . . . . . . . . . . . 19
13. Label Stacking . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Label Swapping . . . . . . . . . . . . . . . . . . . . . . . . 20
15. Packet Processing Algorithms . . . . . . . . . . . . . . . . . 20
16. Fast Switching . . . . . . . . . . . . . . . . . . . . . . . . 22
17. FEC Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 22
18. Invalid Incoming Labels . . . . . . . . . . . . . . . . . . . 23
19. Flow Aggregation or Merging . . . . . . . . . . . . . . . . . 23
20. Label Encodings . . . . . . . . . . . . . . . . . . . . . . . 23
21. Anycast in 6LSA . . . . . . . . . . . . . . . . . . . . . . . 23
22. Multicast in 6LSA . . . . . . . . . . . . . . . . . . . . . . 24
23. Security Considerations . . . . . . . . . . . . . . . . . . . 24
24. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 25
25. Informative Referneces . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Chakravorty, et al. Expires January 10, 2009 [Page 3]
Internet-Draft IPv6 Label Switching Architecture July 2008
1. Introduction
Several approaches have been developed over the past decade to
provide QoS in large networks. These include DiffServ, RSVP, MPLS,
ATM, extensions to routing protocols, and proprietary mechanisms.
Some of these techniques can also be applied to IPv6 transport but
not directly. IPv6 offers strong features to enable QoS delivery,
most significant among them are the Flow Label and the Routing Header
extensions.
The IPv6 Label Switching Architecture (6LSA) specified here enables
fast switching using 20-bit labels instead of 128-bit IPv6 addresses
and thereby provides memory and processing savings, the latter
because address fetches for low-powered, handheld devices, which are
mostly 32-bit architectures, could be up to four times as fast. The
architecture allows temporary replacement of labels inserted by a
source node with the proviso that the original labels are reinserted
prior to the packet arriving at its destination.
This document introduces an architectural framework for the use of
IPv6 packet header Flow Labels for setting up labeled paths of local
significance to provide services that cannot be provided by a purely
routed, connectionless approach. The 6LSA allows local label
generation in a network node. It also allows a network management
entity updating available label tables, across the network to reduce
man-in-the-middle attacks.
This local label generation coupled with dynamic labeling helps the
6LSA to provide the means for mobile nodes to set up labeled paths,
automatically and/or manually, for end-to-end QoS delivery or for any
other service delivery.
2. Overview
The IPv6 label switching mechanism makes use of the 20-bit Flow Label
in the IPv6 header to assign flow IDs which are used for labeled
paths, also called IPv6 label switched paths (6LSPs). The
specification of IPv6 label is in conformance with RFC 3697 RFC 3697
[1], IPv6 Flow Label Specification, in which the use of Flow Label
has been recommended for establishing different types of flows at the
source nodes and packet classification in the intermediate nodes.
The proposed mechanism of IPv6 label switching broadens the scope of
the use of Flow Labels beyond its simple use for packet
classification to its use of packet classification and forwarding.
The component of the Flow Label, called Local label value, is locally
assigned in the packet header along a path. This part of the Flow
Label can be different from the corresponding part of the original
Chakravorty, et al. Expires January 10, 2009 [Page 4]
Internet-Draft IPv6 Label Switching Architecture July 2008
Flow Label assigned by the source and as such this component is
temporary and has only per hop significance unless such significance
is extended to multiple hops.
The 6LSA concept of Flow Label assignment is applicable to the 6LSA
domain only. Whether the concept is applicable to domains outside
the 6LSA is of no concern to 6LSA unless there is one-to-one mapping
in the labels and implied significance.
In a conventional router, the forwarding decision is independently
made in each router as the packet travels from one router to the
next. In each router, the packet header is analyzed using a network
layer routing algorithm to find the best next-hop that is often the
shortest distance to the next router. Since this forwarding in each
router is "independent" of how the previous packet for the same
destination was processed and forwarded, the routing is considered
connectionless.
The process specified in this document supports two functions: first,
grouping of packets of similar flow requirements into a Forwarding
Equivalence Class (FEC), and second, forwarding all packets belonging
to an FEC along the same path. The forwarding of packets does not
necessarily have to be along the paths as determined by the routing
algorithms or by manual configuration provided there is no looping of
packets caused by the 6LSA forwarding.
In 6LSA, the FEC is encoded in the Flow Label field as a non-zero
value, which is also called label in this document. The label is
available in one of 3 ways: (1) locally generated, based on certain
algorithm or policy, (2) in the incoming packet, as Flow Label from a
source node, or (3) distributed, through a label distribution
process. The assignment of a label to an FEC is identified as a
binding. Once the binding of a label is created and provided to an
FEC, the forwarding policy of the packet may be represented through
the label and is maintained at a minimum for the duration of the
session.
The selection of the FEC is based on one or more flow
characteristics. The selection of flow characteristics and therefore
of FEC is an administrative, service or policy decision, or a
combination thereof. Such a decision is meant to support certain
traffic requirements, such as availability bandwidths on certain
links, VPN (Virtual Private Network) configuration, values encoded or
configured into the Traffic Class field of IPv6 packet headers, or
requirements conveyed by the source or administrative entity or by
other means. A superset of global FEC selections and corresponding
label values are included in this document.
Chakravorty, et al. Expires January 10, 2009 [Page 5]
Internet-Draft IPv6 Label Switching Architecture July 2008
Merging of flows on a single 6LSP is possible with the consequence
that two or more flows are inseparable and indistinguishable inside a
6LSA domain from the merger node to the egress or penultimate node.
Merging of flows may lessen the amount of state maintained within
6LSA nodes, however, since there is no stacking of labels in 6LSA and
each packet's label has to be examined individually, the processing
saving is insignificant.
The 6LSA label supports the forwarding of packets belonging to the
same FEC along an IPv6 Label Switched Path (6LSP). For the lead
packet of each flow, traffic class, source and destination addresses,
and possibly other special handling requirements conveyed by the
source (e.g., by a control plane protocol) may be examined for FEC
identification and label selection. This decision process is
independently carried out on each 6LSA node transited by the lead
packet across a 6LSA domain. Subsequent packets of the same flow (or
a group of flows) typically do not go through the same process of
label selection and assignment because the label binding to an FEC
and egress interface has been cached. So, the subsequent packets can
be rapidly forwarded.
The 6LSA domain routers are not cognizant of labels outside of their
domain.
3. Terminology
This section provides a general overview of alphabetically arranged
terms that are used in this document. Some of these terms are more
precisely defined in the later sections of this document.
Chakravorty, et al. Expires January 10, 2009 [Page 6]
Internet-Draft IPv6 Label Switching Architecture July 2008
6LSA a set of nodes that perform 6LSA routing and
forwarding operations and are in one
6LSA domain
6LSP label switched path, a virtual path, through
a pair or more 6LSA nodes
6LSR IPv6 label switching router that is capable
of forwarding IPv6 packets based on
FEC attributes
FEC Forwarding Equivalent Class, collection of IP
packets that receive the same forwarding
treatment and are forwarded over the
same 6LSP
Flow sequence of packets identified by the
Flow Label
Switching table forwarding table that comprises packet
forwarding information
4. Distinguishing Characteristics of 6LSA
The 6LSA characteristics justify its application wherever IPv6 is
deployed and where QoS network performance or other service delivery
is required, or where other available packet forwarding mechanisms
cannot deliver packet performance end-to-end. The following special
characteristics of 6LSA are listed here in no particular order:
o 6LSA technology offers a methodology for use of flow label in
the IPv6 header which is as yet unused.
o No Extraneous Label Bindings - 6LSA eliminates the need for
using extraneous labels (labels from other than Layer 3) and/or
eliminates the need for associated label distribution across the
network
o No IPSec Constraints - 6LSA does not need to use the Layer 4
ports to define a flow and therefore can be used with IPSec VPNs or
other IPSec based services.
o Free of Layer 2 Overheads - Being a layer 3 packet forwarding
solution, the 6LSA does not need a layer 2 packet forwarding
mechanism such as ATM and as such 6LSA avoids ATM's fragmentation and
re-assembly delays and associated header overhead. It also avoids
the need for added signaling and state machine mechanisms to provide
Chakravorty, et al. Expires January 10, 2009 [Page 7]
Internet-Draft IPv6 Label Switching Architecture July 2008
ATM switched paths and ship-by-night capabilities. Additionally,
being based on routing protocols (6LSRs peer in Layer 3), 6LSA tends
to avoid the potential for O(N2) and O(N3) problems.
o Deployment Ease - The 6LSA can be deployed over all layer 2
protocols such as Ethernet and PPP. There is no layer 2 interface
limitation in 6LSA.
o Extensive QoS Label Space - The 20-bit Flow Label in addition
to the 8-bit Traffic Class field can provide a huge traffic
classification space, both the fields may be used together in the
6LSA.
o Feature Visibility - All of the IPv6 packet header features are
available while the packet is enroute to destination as such IPSec or
similar packet encryption does not disable the delivery of QoS or
other similar services that 6LSA can provide.
o IPv6 Transition Support - During the transition from IPv4 to
IPv6, the latter is generally deployed as network-islands surrounding
IPv4/MPLS core. The implementation of 6LSA in native IPv6 edge
networks will greatly facilitate traffic engineering between the edge
and the core by mapping 6LSA Global Label value in the Flow Label to
be carried over to MPLS label in the core if the FEC representation
by the flow label is common in both domains, for example, if the
label represents a given bandwidth, say.
o Security Enhancement - Since 6LSA allows node-local generation
of labels, such generation, where adopted, can be made totally random
or periodically synchronized across the 6LSA domain to considerably
reduce man-in-the-middle attacks.
To summarize, 6LSA provides a significant layer 3 capability for
switching IP packets - with little or no added overhead for
signaling.
5. Routing Versus Switching of IP Traffic
The routing of packets on the Internet has the following essential
characteristics in addition to connectionless, non-sequential packet
transport: 1) The paths are not dedicated virtual paths, and 2) There
is generally no delivery or QoS guarantee - only a single class of
traffic is available.
Switching of packets has the following basic characteristics: 1) The
routing of packets is connection-oriented; the flow of packets
comprises sequential packets, 2) The packets travel over dedicated,
Chakravorty, et al. Expires January 10, 2009 [Page 8]
Internet-Draft IPv6 Label Switching Architecture July 2008
virtual paths or virtual circuits (VCs) which are either temporary or
permanent, and 3) Switching is generally associated with certain
delivery guarantees and traffic classification.
The issues with switching are:
* There are delays caused by VC setup time across the network.
* There is a need for VC state maintenance.
* IP address to VC translation latency is always present however
small.
* Potential is there for large resource wastage in case of a link or
node failure in IP virtual network over switched network, for example
IP over ATM that may cause N2 and N3 problems.
The design of 6LSA overcomes the above disadvantages of switching by
making the establishment of the switched path hop-specific but flow
session bound.
6. 6LSA Basic Components and Their Attributes
In this section, the 6LSA basic components and their attributes are
defined.
6.1. Flow
A flow in 6LSA is identified by the label value in the Flow Label
field in the IPv6 packet header. All packets belonging to the same
flow must be sent with the same Flow Label per hop, at a minimum, and
from the source node to the destination node, at a maximum. The
label in the lead packet and that in the subsequent packets of a flow
may be different or the same depending upon the algorithm selected.
In 6LSA domain, non-zero label identifies a best effort delivery.
6.2. Forwarding Equivalence Class (FEC)
The FEC represents a group of IPv6 packets that all receive the same
forwarding treatment. The forwarding treatment may be based on one
or more attributes associated with an FEC or other processing
requirements imposed on the flow externally.
Several flows from multiple sources may receive the same forwarding
treatment and thus belong to the same FEC. For example, if multiple
flows are to be processed in the same outgoing queue because they all
deliver the same service, they are identified by the same FEC.
Chakravorty, et al. Expires January 10, 2009 [Page 9]
Internet-Draft IPv6 Label Switching Architecture July 2008
6.3. Label
A label is the 20-bit, fixed length Flow Label identifier in the IPv6
header. A node in the 6LSA binds the Flow Label to a Forwarding
Equivalency Class (FEC) and uses it to forward the packet. The label
may thus represent the FEC. In the 6LSA, the FEC indicates the
forwarding treatment a group or class of packets (with a given label)
receives. This label and the FEC it represents have only local (per
hop) significance unless the attributes associated with a FEC are
shared among multiple hops.
A label is thus associated with the characteristics of a flow which
is represented in the FEC.
A flow label is assigned to a flow by the flow's source node. New
flow labels must be chosen (pseudo-)randomly and uniformly. The
purpose of the random allocation is to make any set of bits within
the Flow Label field suitable for use as a hash key by routers, for
looking up the state associated with the flow.
A label in an incoming packet is called an "incoming label", and that
in an outgoing packet is called an "outgoing label".
The 6LSA nodes are permitted, but not required, to verify that the
flow conditions are satisfied. If a violation is detected, it should
be reported to the source by an ICMP parameter Problem message, Code
0, pointing to the high-order octet of the Flow Label field.
A source node must not reuse a flow label for a new flow within the
maximum lifetime of any flow-handling state that might have been
established for the prior use of that flow label.
The first 7 bits of the Flow Label are of global nature that all
nodes in a 6LSA domain need to treat identically. This component of
the Flow Label thus must be maintained end-to-end without any change.
The security implications of maintaining Global Labels end-to-end are
clear and therefore will not be addressed further in this document.
A primary selection of Global Label value is presented here below for
FEC usage as guidance. Note that the most significant bit is the
left most bit. In the selection provided below, only the first 3
leftmost bits identify the superset of the flow characteristics. The
next four bits provide further identify granularity of the flow
characteristics.
The selection for the Enterprise Specific category allows an
enterprise such as a corporation, service provider, or governmental
agency to have their own specific Global Value component to take
Chakravorty, et al. Expires January 10, 2009 [Page 10]
Internet-Draft IPv6 Label Switching Architecture July 2008
advantage of enterprise's unique feature sets and for added security.
The last 13 bits can be locally selected by each node or a group of
nodes; they are typically hop-specific. This hop specificity may
extend for more than one hop. Any node not associated with this hop
need not adhere to the selected FEC. The Local Label Value is of
local significance only unless it is extended to more than the local
hop associated nodes.
The Global Label value provides space for 8 major categories each
with 16 different subcategories. A substantive subcategory of
reserved space is also available for future or application specific
use.
The total Local Label value space available to 6LSA nodes is between
1 and 2^13 times yielding the ability to uniquely identify 8,192
6LSPs per physical (or virtual) port per hop. The label space
applies to each physical interface.
Chakravorty, et al. Expires January 10, 2009 [Page 11]
Internet-Draft IPv6 Label Switching Architecture July 2008
+--------------------------+-------------+--------------------------+
| FEC (First 3 Bits) | Next 4 Bits | Purpose |
+--------------------------+-------------+--------------------------+
| No FEC (000) | 0000 | |
| Domain Specific (000) | 0001 - 1111 | |
| ------------------------ | | |
| VPN (001) | 0001 | (IPSec - Tunnel Mode) |
| | 0010 | (IPSec - Transport Mode) |
| | 0011 | (Special Encryption) |
| | 0100 | (VRF) |
| | 0101 | (End Network Specific) |
| | 0110 - 1111 | (Reserved) |
| ------------------------ | | |
| TE Subset/ | 0001 | (DiffServ) |
| QoS Enhancement (010) | 0010 | (RSVP) |
| | 0011 | (RSVP-TE) |
| | 0100 | (SIP) |
| | 0101 | (H323) |
| | 0110 | (Large File) |
| | 0111 | (Circuit Emulation) |
| | 1000 | (Fixed Bandwidth) |
| | 1001 | (Video Streaming) |
| | 1010 | (Multicast) |
| | 1011 | (Anycast) |
| | 1100 | (Queue Weighting) |
| | 1101 | (Precedence Sensitive) |
| | 1110 | (Enterprise Signal) |
| | 1111 | (Reserved) |
| ------------------------ | | |
| Encapsulation (011) | 0001 | (IPv6 in IPv6) |
| | 0010 | (IPv4 in IPv6) |
| | 0011 | (Other in IPv6) |
| | 0100 | (Enterprise Specific) |
| | 0101 - 1111 | (Reserved) |
| ------------------------ | | |
| Enterprise Specific(111) | 0000 - 1111 | (Reserved) |
+--------------------------+-------------+--------------------------+
As an example, between nodes A and B in a 6LSA domain, if there is a
group of packets that are tunneling IPv4 packets in IPv6, then the
first 7 bits of the label for all these packets will be marked
0110011. A 6LSA node may choose to use the remaining bits to signify
different physical or logical ports or such other characteristics
that are locally assignable.
For each of the above selections, up to 8,192 additional local
selections are available for each FEC group for one or more hops as
represented by the remaining 13-bit space.
Chakravorty, et al. Expires January 10, 2009 [Page 12]
Internet-Draft IPv6 Label Switching Architecture July 2008
A total of 16 selections are available to an enterprise for use as
desired. For each of these 16 selections, an enterprise may use
additional 13 bits in the remaining flow label space for node
specific processing needs.
It is envisioned that an application, middleware, end-system socket
software or network node software will be enabled to encode the
needed FEC for a flow just as DSCP marking is encoded for DiffServ.
In this document, the nomenclature of label or Flow Label is
variously used though the meaning is the same and while referring to
the word label used in other technologies, such as in MPLS, the
context of the technology is also mentioned to distinguish the
application and meaning of the word.
6.4. Labeled Packet
In 6LSA, a labeled packet is an IPv6 packet whose header has a non-
zero Flow Label value.
If an incoming packet into a 6LSA node has a zero label value and it
is not a lead packet, it is assigned a non-zero label value before it
is forwarded. This is because in 6LSA, a zero label is used to
indicate that the packet is a best-effort packet.
The label from a flow in the 6LSA may be transferred to a non-6LSA
network layer or to a non-6LSA data link layer as long as there is a
field available that can carry the 6LSA label. The particular
encoding technique and its significance must be agreed by both the
layers - layer 3, the network layer, and layer 2, the data link
layer. Specifics of the method of this encoding are outside the
scope of this document.
6.5. IPv6 Label Switching Router (6LSR)
A router operating in the 6LSA is an IPv6 label switching router,
called 6LSR, which performs as a minimum the two 6LSA functions of:
1) replacing (swapping) an incoming label in a packet with an
outgoing label, and 2) forwarding the packet based on the appropriate
forwarding treatment.
6.6. Lead Packet
A packet arriving at a 6LSA node is a lead packet if it is the first
packet of the flow that this node has received. A lead packet may or
may not be the first packet of the flow that the upstream router or
6LSR forwarded to this 6LSR. It is possible that the first packet in
the flow is lost or misdirected, or for that matter, first few
Chakravorty, et al. Expires January 10, 2009 [Page 13]
Internet-Draft IPv6 Label Switching Architecture July 2008
packets in the flow are lost or misdirected.
All lead packets, whether they are the first packet from the upstream
6LSA node or not, are treated like they were the first packet of the
flow.
Lead packets have no existing entry in the switching table of a 6LSR
or 6LSA node.
6.7. Switching Table
A switching table in 6SLA is often called the forwarding table in the
networking literature. This table comprises the following
information as they become available:
-- Label value from the lead packet, if there is a non-zero
label otherwise a zero value is entered
-- Incoming interface, that is, interface on which the
packet arrived
-- Next hop IPv6 address
-- Outgoing interface, that is, the interface on which the
packet is forwarded to the next-hop 6LSR
-- FEC value that identifies the forwarding operation that
needs to be performed on a packet
The outgoing label entered in the switching table has to be unique so
that this node or 6LSR is able to identify a unique LSP for the
packet.
Additional information that may be available in the switching table
is as follows.
* The data link layer and encapsulation to use
* How the label value, typically the Local Label value, needs
to be encoded in the label field
* Timers associated with the packet
* Last packet in the flow
* Information with regard to how to discard labels or packets
The format and content of the switching table entry are
implementation and configuration specific and are not specified here.
7. Attributes of Label Binding
The binding of a label to a FEC is based on known attributes of the
packet or on externally applied constraints. The binding of a label
Chakravorty, et al. Expires January 10, 2009 [Page 14]
Internet-Draft IPv6 Label Switching Architecture July 2008
to a FEC is local to a 6LSA node unless such binding is promulgated
across the network through some exterior means such as a using a
label distribution protocol (LDP) commonly used for MPLS. LDP is
outside the scope of this document.
8. IPv6 Label Switched Path (6LSP)
A label switched path in the 6LSA is called 6LSP and identifies a
virtual circuit through which one or more flows are routed to the
next-hop 6LSR.
The sequence of 6LSA nodes, that is, the sequence of nodal interfaces
through which labeled packets are transported represents a 6LSP. A
6LSP is thus represented by a label between any two nodes, and by one
or more sequence of labels between multiple nodes, or between two or
more hosts, or any combination thereof. Conversely, a 6LSP may also
represent the FEC binding of each flow in each of the 6LSR on the
6LSP. In this regard, 6LSP closely resembles a virtual circuit (VC)
in ATM, and LSP in MPLS.
9. 6LSA Architectural Functionalities
This section describes 6LSA functionalities including label
acquiring, label binding to FEC, and label swapping.
a) The 6LSA comprises two basic functions: first,
grouping of packets of similar flow requirements
into a FEC, and second, speedily forwarding all
packets belonging to an FEC along the same path -
including flow merging when multiple flows have
the same FEC characteristics.
b) A 6LSA domain edge 6LSR replaces the incoming
Local Label in a packet with an outgoing Local Label
establishing a unique 6LSP for one or more packets
in the flow associating it with the same incoming
Flow Label and source and destination address
combination. Each 6LSA node ensures there is no
duplication of 6LSPs from itself to the downstream
node for the same FEC.
Chakravorty, et al. Expires January 10, 2009 [Page 15]
Internet-Draft IPv6 Label Switching Architecture July 2008
c) An intermediate 6LSR receives a flow on a unique
6LSP. It replaces the incoming label with a FEC
bound outgoing label based on the needed local
treatment of the packet. The last 13 bits in the
label that this 6LSR encodes represent the local
6LSP that this 6LSR sets up. This last locally
encoded 13-bit value may add unique characteristics
to the treatment of the packet or its path in
addition to the global FEC treatment requirements.
The total label value is entered in the local
switching table. The packet is then forwarded to
the next downstream 6LSR. The first 7 bits
representing global FEC part may not be changed by
a 6LSA node.
d) Within a 6LSA domain, if a router is a 6LSR, it
swaps the label, if it is not a 6LSR; it lets the
flow pass without any label changes.
e) Each 6LSP is maintained at least for the duration
of the session of transport of all packets in a
flow. In 6LSA, labels may be maintained for a
pre-determined time after a session has ceased to
exist, that is, for a fixed amount of time
determined a-priori after packets belonging to a
flow have ceased to arrive.
There are two salient points that need to be emphasized. First, the
same label is not used for any two 6LSPs from an upstream 6LSR to a
downstream 6LSR for the same pair of physical ports. Second, the
last 13 bits of a label may have little significance for the
downstream 6LSR unless it is aware of the significance of these bits
a-priori. It has relevance for the upstream 6LSR which uses it to
bind an FEC to the label and then uses the 6LSP to forward all the
packets in a flow. The 6LSP thus becomes a representation of the FEC
and forwarding pointer for the upstream 6LSR. The only time a 6LSP
and therefore the associated full label has any relevance value to
the downstream 6LSR is when the label bindings are distributed across
a given 6LSA domain.
A 6LSA label by default creates a tunnel for all packets in a flow
since the significance of the label bound to an FEC requires a
special handling by every node for all packets in the flow which is
not unlike a tunnel. The processing of packets based only on the
label, once a specific label has been assigned to a flow for each
hop, is similar to processing of a tunneled flow where the processing
is generally determined by the tunnel header bits.
Chakravorty, et al. Expires January 10, 2009 [Page 16]
Internet-Draft IPv6 Label Switching Architecture July 2008
The incoming flows into any of the nodes can arrive on one or more
6LSPs. If the outgoing flows are merged onto the same 6LSP, the
downstream node receives the merged flow with the same label.
Packets belonging to a merged flow although are from different flows,
they each still need to be examined by their label. However, once
the flows are merged, distinction between individual flows may not be
necessary for packet forwarding.
10. Label Assignment
In the 6LSA, the decision to assign or bind a label to a particular
FEC is made by a 6LSA node, generally by the ingress node if it is
not the origination point for that flow. The 6LSA host or node then
informs the next-hop, downstream node of this binding via this
labeled IPv6 packet or via some other method depending on the nature
of label generation and distribution methodologies.
Three models have been identified for acquiring label space. The
first model specifies how the labels can be generated locally; the
second model refers to how labels can be acquired from label
distribution, and the third, how labels are acquired from incoming
packet headers. Only one of these three models of label assignment
is allowed in a network of 6LSA-based nodes.
Once a label binding is available, the 6LSA requires that the label
binding be retained for the duration of the session.
It is quite possible that multiple flows may require the same label
and label binding to a single FEC. In these cases, all such flows
may be multiplexed or merged together as one outgoing flow and
forwarded on one 6LSP using the same label. At the de-multiplexing
6LSA node downstream, the flows must be discernible through the
unique source and destination addresses or through other means.
The 6LSA does not prevent any 6LSA node from storing any label
generated at a time different from when it is being used nor does it
prevent a node from using any label that was used earlier or
retrieved from a flow that used an algorithm or a model other than
those identified here.
10.1. Locally Generated Label Model
In this model, 6LSA allows a node to generate its own labels to be
used in the IPv6 header. The specification for the algorithm(s) used
to generate the 20-bit labels is beyond the scope of this document.
An example algorithm for generating flow labels is a pseudorandom
Chakravorty, et al. Expires January 10, 2009 [Page 17]
Internet-Draft IPv6 Label Switching Architecture July 2008
number generator outputting values within the parameters algorithm in
which the bit values are within the parameters specified in Section
6.1, Label. It is envisioned that a set of labels will be generated
for every service class, elastic and inelastic, such as file
transfer, voice, video, etc.
The Locally Generated Label model does not preclude manual generation
of a label or range of labels through a configurator or similar other
means. The locally generated label may have a value related to one
or more attributes that is applicable to the next-hop node or nodes
across the network.
The 6LSA specification allows labels that are locally generated but
may have non-local significance. Such attributes may be regularly or
randomly refreshed by a network management or other systems.
Methodologies for such refreshment are outside the scope of this
specification. The Global Label part (the first 7 bits) has by
default the same significance for all nodes in 6LSA. However, the
Local Label value (the last 13 bits) may or may not have only local
significance.
This model is not a mandatory part of 6LSA, i.e., a node is not
required to implement this model in order to be considered 6LSA-
compliant. However, when a 6LSA node claims to implement the Locally
Generated Label Model, the implementation must conform to the
specification given in this document.
The use of this model is encouraged because it is simple, efficient
and avoids control plane traffic for label distribution as in the
Distributed Label Model.
The Locally Generated Label Model enhances security since the labels
have local significance only and can be randomly or periodically
refreshed all through the 6LSA domain prior to their use.
10.2. Distributed Label Model
The 6LSA allows distribution of the Local Label (value) space
generated in one or more nodes or externally in a server. The
architecture also allows more than one label distribution protocol
(LDP) and sharing of necessary information amongst the label
distribution peers.
Mechanisms or protocols that allow a Local Label distribution and do
not violate any of the 6LSA specification with regard to use of such
labels and the operation of 6LSA nodes are allowed. The specifics of
label distribution protocols are outside the scope of this document.
Chakravorty, et al. Expires January 10, 2009 [Page 18]
Internet-Draft IPv6 Label Switching Architecture July 2008
The specifics of the process by which a node binds a label to a FEC
are implementation specific and thus outside the scope of this
document.
The Distributed Label Model enhances security if the labels have
local significance only and can be randomly or periodically refreshed
all through the 6LSA domain prior to their use. For reasons of
efficiency, this label model may only distribute the Local Value part
of the label.
10.3. Reuse Label Model
The 6LSA allows a node to reuse existing label available in the node
or obtained from labels in the incoming packets and where the flows
can be associated with unique label bindings.
11. Scope and Uniqueness of Labels
A label in a packet on a 6LSP must be unique to a flow, in any given
direction, between interfaces on peering nodes that are one hop
apart.
A flow always originates at the upstream source node in the 6LSA
domain, continues through multiple 6LSRs and terminates in the
destination node which also must exist in the 6LSA. Such a flow must
carry a non-zero label in its lead packet.
In the unusual event where two flows have lead packets with the same
label, the follow-on labels used by the ingress routers are kept
different for the two flows. In all 6LSR routers, the discriminator
for these two lead packets is the physical port, source and
destination address pair or such other means as allowed by the 6LSA
implementer.
To summarize, the discriminator for the incoming packets from an
upstream 6LSR to this 6LSR is the 6LSP and the discriminator for the
outgoing packets from this 6LSR to a downstream 6LSR is the FEC.
Generally, for a flow, an incoming label represents the upstream 6LSP
and an outgoing label represents the downstream FEC. In many cases,
the same label may be usable or used for both.
12. Label Retention Mode
If a 6LSR B receives a label binding from a 6LSR A for a particular
FEC via LDP, even though B is more than one hop apart from A, then
such binding may be retained or discarded by B. If the binding is
Chakravorty, et al. Expires January 10, 2009 [Page 19]
Internet-Draft IPv6 Label Switching Architecture July 2008
retained, then this binding may be used later when A becomes a next-
hop 6LSR to B. If the binding is discarded, then B will have to
acquire a new binding for traffic from A through one of the three
models described in Section 10.
13. Label Stacking
The 6LSA does not allow IPv6 label stacking. There is only one label
in an IPv6 packet and this label must be in the Flow Label field in
the IPv6 packet header. The 6LSA allows multiple label spaces per
platform; however, the use of the label must conform to the
specifications stated in this document. It should be noted that this
does not preclude other non-IPv6 label stacking such as layer 2 label
stacking.
14. Label Swapping
Label swapping or label switching is a process in which the incoming
label in a packet is replaced with an outgoing label. In this
document, this process is associated with multiple other activities.
These activities include matching the switching table entries with
certain incoming packet header fields, binding a label to the FEC,
updating the switching table and finally, forwarding the packet.
However, when the swapping involves only incoming label replacement
with an outgoing label, it is called label switching, which typically
is a fast process and may be carried out in the interface card
itself.
15. Packet Processing Algorithms
The 6LSA packet processing algorithm refers to handling of packets
that arrive from hosts in a 6LSA domain. The 6LSA packet processing
provides for QoS priority, VPN handling and other forwarding
treatments.
At a source node when an IPv6 packet is created, the Flow Label field
is encoded with a Global Value of the label depending on the nature
of the application. The Global value represents the generic nature
of the service or flow characteristics. It may be incognizant of and
unrelated to the hop-specific flow constraints that may exist. This
Global Value encoding is then followed by the hop specific Local
Value label encoding. This value may be locally generated, provided
by a routing or such other protocol, manually configured or a
combination thereof.
Chakravorty, et al. Expires January 10, 2009 [Page 20]
Internet-Draft IPv6 Label Switching Architecture July 2008
An example can best expound the labeling at a source node. Thus if a
source node application intends to send a SIP packet to the far end,
it determines the related Global Label value of the label which is
0100100 from the table provided in Section 6.3. Thereafter if the
local hop specific treatment requires that it be sent on a specific
physical port for a prioritized flow (since this signaling), it will
search the configuration information provided to it for a
corresponding applicable Local Label value. Let's assume, this flow
has to go through the fourth port and has the highest priority
handling requirement. Let's also assume that this is represented by
0000010000001. The total label value is then 0100100 00000010000001
and this then is encoded in the Flow Label field. Note that the node
carries out a few other activities such as inserting in the switching
table the source and destination of the packet, its Global and Local
label values, and such other needed items. This switching table can
also be used for holding configuration information such as FECs and
related Local Label values.
The Local label value may well have been determined from the routing
table as much as the Global Value from the Traffic Class field in the
packet header. How this determination is made in any specific 6LSA
domain or node is implementation specific.
In this example, the two characteristics of the flow represent the
FEC of the flow and the selected 20-bit label is then said to be
bound to this FEC.
Once the label has been bound to the FEC, the source node continues
to send packets encoding them with the same label for this flow. The
path of the flow then becomes the 6LSP for the flow.
At the next hop, an intermediate 6LSA node receives the packet on its
third port connected to the source node. It first checks to see if
either the Global or Local Label value exists in its Switching Table.
If there is a match available for the Global Value label, it goes to
Step 2, otherwise it follows Step 1.
Step 1: On examining the Global Label value, it determines the nature
of the flow. From information provided through routing protocol,
manual configuration or otherwise, it knows that such signaling flows
need to be sent out via the second port of the node and that all such
packets have to be queued ahead of all other packets. It identifies
a proper Local Label value, which say is: 0001010000001. It replaces
the incoming Local Label value with this value, queues the packet
ahead of all other packets in the outgoing buffer and forwards the
packet through the second port. This then presents the processing of
packet in the intermediate node. As was stated earlier for the
source node, additional processing takes place in the intermediate
Chakravorty, et al. Expires January 10, 2009 [Page 21]
Internet-Draft IPv6 Label Switching Architecture July 2008
node regarding updating of the switching table with the needed
information from the outgoing and incoming packets.
Step 2: If there is a match for the Global Label value, then the
Local Label value field is also searched in the Switching table and
if they both match, the incoming Local Label value is switched and
the packet is sent out via the second port. This continues for all
packets that have both values match. However, if there is no match
for the Local Value field, then the received packet is treated as the
lead packet of another flow coming from the same source and the
processing is identical to Step 1 since a new 6LSP has to be
established for this flow.
In uncommon cases, a source node may create two flows for the same
destinations with two FECs. If it does, the intermediate node has to
assign two different labels and provide two label bindings for the
two flows.
The processing that takes place in the second and subsequent
intermediate nodes is the same as that in the first.
The process at the destination node is similar to the first
intermediate node with the variation that the packets are forward to
the corresponding application in this node instead of forwarding them
out of this node.
Duplication of flow labeling is not possible since the local label is
always unique for each flow and LSP although the same label may be
used for different flows in unrelated hops out of the same node or
other nodes in the same 6LSA domain.
16. Fast Switching
When a 6LSR can simply swap an incoming label with an outgoing label
without going through insertion of new entry in the switching table
for that packet, then this swapping is termed fast switching in this
specification. This occurs when flow characteristics are well-
established or deterministic enough that no additional processing is
needed. One instance of this can occur in a 6LSA node where there is
one incoming port and one outgoing and there is only one FEC such as
is found commonly in the edge networks or other small or campus
network nodes.
17. FEC Mapping
Each FEC may map to a set of flows, node and route characteristics
Chakravorty, et al. Expires January 10, 2009 [Page 22]
Internet-Draft IPv6 Label Switching Architecture July 2008
which may be represented in the switching table. The switching table
may consist of more than one entry that a particular FEC can be
mapped to and forwarded via a labeled packet.
18. Invalid Incoming Labels
An incoming or acquired label is invalid if it has a value that does
not allow the 6LSA node to bind the label to a FEC. Such a label may
be discarded after the lead packet is forwarded. Invalid labels may
not include a zero-labeled packet.
19. Flow Aggregation or Merging
If it can be determined that two or more flows are destined for the
same network or non-6LSA domain, then flow merging are implemented.
The advantages are: less state is maintained in each 6LSR and there
is no need to differentiate between individual flows after the merge
point.
The 6LSA allows aggregation of labels when FECs represent address
prefixes. Since IPv6 address prefixes are aggregatable, aggregation
of FECs corresponding to aggregatable prefixes is allowed in the
6LSA. The extent of aggregation is a function of the address
aggregation, granularity of service desired or both. Such
aggregation may further be decided by the IPv6 packet header Traffic
Class parameters.
20. Label Encodings
The 6LSA allows encoding of the label value in layer 2 protocols such
as in ATM packet's VPI/VCI fields. Since only one label is used and
that each such label is uniquely identifiable in the 6LSA, encoding
the label in the ATM VPI/VCI field is feasible. Considerations with
respect to how flows are identified, the FEC-based forwarding
treatment, and flow merging issues, need careful planning in the
layer 2 label encoding.
How a 6LSA label value is encoded in the ATM VPI/VCI field is outside
the scope of this document.
21. Anycast in 6LSA
IPv6 defines the anycast address like a regular unicast address with
a prefix specifying the subnet and an identifier that is set to all
Chakravorty, et al. Expires January 10, 2009 [Page 23]
Internet-Draft IPv6 Label Switching Architecture July 2008
zeroes. Anycast packets delivered to this address are delivered to
one router in that subnet. There are reserved subnet anycast
addresses such as for mobile IPv6 Home-Agents anycast. The 6LSA
allows the use of anycast addressing. Whenever a 6LSR is a node in
any anycast subnet, such a subnet may be a 6LSA, a subset of 6LSA or
some other part of 6LSA.
When an anycast packet arrives in anycast subnet 6LSR where the
subnet is a part or whole of 6SLA, the 6LSR binds the packet to the
appropriate FEC which has anycast routing as part of the forwarding
treatment attributes of the FEC. The packet is thus forwarded to a
next-hop 6LSR through an interface determined by the FEC attributes
related to anycast forwarding.
22. Multicast in 6LSA
IPv6 defines the multicast address by the high-order octet FF or
11111111 in binary notation and 4 bits for the scope of the multicast
and an identifier bit that indicates whether the multicast address
belongs to a well-known IANA multicast address group or is a
temporary address.
The 6LSA allows the use of multicast addressing. A multicast tree
may be a 6LSA, or a subset of 6LSA. For multicast transmission, the
6LSR binds the packet to a FEC which may represent multicast routing.
The packet is thus forwarded to a next-hop 6LSR through an interface
determined by the FEC attributes related to multicast delivery. See
Section 6.3 above.
23. Security Considerations
The 6SLA allows Security Association (SA). If the security
association partners are outside the 6SLA, then there is no effect on
the 6SLA by the SA whether the mode of operation is in the transport
mode or in the tunnel mode.
In the transport mode of SA, only the packet payload is subject to
encryption or authentication, so the IPv6 packet header features are
not affected and the 6LSA being a transport mechanism that sets up
6LSPs and provides specific FEC-driven forwarding treatment, there is
no impact on the 6LSA or impact on SA operation by the 6SLA.
In the tunnel mode of SA, the SA requires an outer wrapper IPv6
packet. The sending gateway wraps the whole IPv6 packet including
the content. The receiving gateway performs the checksum on the
outer wrapper packet and then unwraps the packet and verifies the
Chakravorty, et al. Expires January 10, 2009 [Page 24]
Internet-Draft IPv6 Label Switching Architecture July 2008
checksum of the inner packet through end-to-end SA. If the outer
wrapper packet conveys the Flow Label value of the inner packet, then
6SLA provides the 6LSP transport based on the inner label value,
otherwise the transport indicates the outer label value. Here also,
there is no impact on the 6LSA based transport of the secure packets
or vice versa.
The Authentication Header (AH) is used in IPv6 for authentication of
individual packets to prevent common Internet-based attacks such as
IP address spoofing and session hijacking. The computation of
cryptographically secure checksum over the payload as well as some
fields of the IPv6 and extension headers has to take place between
the SA partners. This computation does not include the Flow Label
field in the packet header. This maintains label transparency in the
6SLA. Authentication can be either in the transport mode or in the
tunnel mode.
The 6SLA security considerations that apply to Encrypted Security
Payload (ESP) header comprise encryption modes that are categorized
as transport mode or tunnel mode. In the transport mode, no
encryption of the Flow Label field is performed, so the value is
carried through the 6SLA. In the tunnel mode, the issues are the
same as stated here above.
24. Disclaimer
Any affiliation the first two authors have with The MITRE Corporation
is provided for identification purposes only, and is not intended to
convey or imply MITRE's concurrence with, or support for, the
positions, opinions or viewpoints expressed by the authors.
25. Informative Referneces
[1] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
Flow Label Specification", RFC 3697, March 2004.
[2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments",
RFC 2375, July 1998.
[5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
Chakravorty, et al. Expires January 10, 2009 [Page 25]
Internet-Draft IPv6 Label Switching Architecture July 2008
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao,
"Overview and Principles of Internet Traffic Engineering",
RFC 3272, May 2002.
[7] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
January 2003.
[8] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
Authors' Addresses
Sham Chakravorty
The MITRE Corporation
7515 Colshire Dr.
McLean, VA 22102
USA
Email: schakra@mitre.org
Jeff Bush
The MITRE Corporation
7515 Colshire Dr.
McLean, VA 22102
USA
Email: jbush@mitre.org
Jim Bound
NAv6TF
PO Box 570
Hollis, NH 03049
USA
Email: Jim.Bound@ipv6forum.com
Chakravorty, et al. Expires January 10, 2009 [Page 26]
Internet-Draft IPv6 Label Switching Architecture July 2008
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.
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.
Chakravorty, et al. Expires January 10, 2009 [Page 27]