Internet Engineering Task Force S. Chakravorty
Internet-Draft J. Bush
Expires: April 15, 2007 The MITRE Corporation
J. Bound
NAv6TF
October 12, 2006
IPv6 Label Switching Architecture
draft-chakravorty-6lsa-02
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 April 15, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Chakravorty, et al. Expires April 15, 2007 [Page 1]
Internet-Draft IPv6 Label Switching Architecture October 2006
service (QoS) or other service delivery. Through look-ups of 20-bit
labels instead of 128-bit IPv6 addresses, the architecture provides
potential memory and processing savings, the latter through
significantly reduced address fetches for the low-powered, handheld
devices. Although the label from the source is delivered to the
destination unmodified as required for conformance to the basic tenet
of the existing defintion of the 3-tuple flow, the intermediate
network nodes in 6LSA are allowed to temporarily replace the original
label with a label 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.
Chakravorty, et al. Expires April 15, 2007 [Page 2]
Internet-Draft IPv6 Label Switching Architecture October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Distinguishing Characteristics of 6LSA . . . . . . . . . . . . 8
5. Routing Versus Switching of IP Traffic . . . . . . . . . . . . 10
6. 6LSA Basic Components and Their Attributes . . . . . . . . . . 10
6.1. Label . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Forwarding Equivalence Class (FEC) . . . . . . . . . . . . 12
6.4. Labeled Packet . . . . . . . . . . . . . . . . . . . . . . 12
6.5. IPv6 Label Switching Router (6LSR) . . . . . . . . . . . . 13
6.6. Lead Packet . . . . . . . . . . . . . . . . . . . . . . . 13
6.7. Packet Identifier (PID) Field . . . . . . . . . . . . . . 13
6.8. Switching Table . . . . . . . . . . . . . . . . . . . . . 14
7. Attributes of Label Binding . . . . . . . . . . . . . . . . . 14
8. IPv6 Label Switched Path (6LSP) . . . . . . . . . . . . . . . 15
9. 6LSA Architectural Functionalities . . . . . . . . . . . . . . 18
10. Label Assignment . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Locally Generated Label Model . . . . . . . . . . . . . . 20
10.2. Distributed Label Model . . . . . . . . . . . . . . . . . 21
10.3. Reuse Label Model . . . . . . . . . . . . . . . . . . . . 22
11. Scope and Uniqueness of Labels . . . . . . . . . . . . . . . . 22
12. Label Retention Mode . . . . . . . . . . . . . . . . . . . . . 22
13. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 23
14. Label Stacking . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Label Swapping . . . . . . . . . . . . . . . . . . . . . . . . 23
16. Packet Processing Algorithms . . . . . . . . . . . . . . . . . 23
17. Fast Switching . . . . . . . . . . . . . . . . . . . . . . . . 24
18. FEC Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 24
19. Penultimate 6LSR Label Processing . . . . . . . . . . . . . . 24
20. Invalid Incoming Labels . . . . . . . . . . . . . . . . . . . 25
21. 6LSP Control: Ordered and Loose . . . . . . . . . . . . . . . 25
22. Flow Aggregation or Merging . . . . . . . . . . . . . . . . . 25
23. Route Selection . . . . . . . . . . . . . . . . . . . . . . . 26
24. Explicit Routing using Routing Header Extension . . . . . . . 26
25. Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
26. Label Encodings . . . . . . . . . . . . . . . . . . . . . . . 26
27. Anycast in 6LSA . . . . . . . . . . . . . . . . . . . . . . . 27
28. Multicast in 6LSA . . . . . . . . . . . . . . . . . . . . . . 27
29. Security Considerations . . . . . . . . . . . . . . . . . . . 27
30. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 28
31. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 28
32. Informative Referneces . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Chakravorty, et al. Expires April 15, 2007 [Page 3]
Internet-Draft IPv6 Label Switching Architecture October 2006
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 destinaion.
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 QoS for flows 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 of any
other service delivery.
Finally, if it can be determined that two or more flows are destined
for the same network or non-6LSA domain, then flow merging can be
effectively 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 egress 6LSR restores
flow labels for individual flows, a route lookup for the lead packet
of the "first" flow on a merged LSP is all that is required for non-
ingress 6LSRs which results in significant processing savings.
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 labeld
paths, also called IPv6 label switched paths (6LSPs). The
specification of IPv6 label is in conformance with RFC 3697 [1], IPv6
Chakravorty, et al. Expires April 15, 2007 [Page 4]
Internet-Draft IPv6 Label Switching Architecture October 2006
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 labels assigned
in the packet header along a path can be different from the original
Flow Label, assigned by the source, and as such they are temporary
labels with only per hop significance unless such significance is
extended to multiple hops. The original Flow Label always replaces
the temporary labels before the packet is forwarded to its
destination.
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.
As noted in RFC 3031 [2], MPLS Architecture, e. Rosen, et al, IP
packet header contains significantly more information than is needed
for the selection of the best next hop. 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 including flow merginging when multiple flows have the same FEC
characteristics or are destined for the same network.
In 6LSA, the FEC may be 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 packet(s) 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 a label is based on the FEC which itself is based on
one or more packet characteristics. What characteristics should be
chosen for what FEC is an administrative, service or policy decision,
or a combination thereof. Such a decision is meant to support
certain traffic requirements, such as those based on DSCP code
points, or those values encoded or configured into the Traffic Class
Chakravorty, et al. Expires April 15, 2007 [Page 5]
Internet-Draft IPv6 Label Switching Architecture October 2006
field of IPv6 packet headers, or requirements conveyed by the source
or administrative entity by other means. This selection and encoding
procedure is outside the scope of this specification. Selection of
FEC may be a configurable parameter of the router, server, host or
any other device that implements this specification of 6LSA. Several
conceptual models for how to build and use the 6LSA labels are
introduced in this document.
The label space available to 6LSRs is between 1 and 2^20 yielding the
ability to uniquely identify 1,048,575 6LSPs. This label space
applies to each physical interface. 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 merge
point 6LSR to the egress or penultimate 6LSR. Merging of flows
lessen the amount of state maintained within 6LSRs and look-up memory
and processing.
The 6LSA label supports the forwarding of packets belonging to the
same flow (or group of flows) and 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) are examined for FEC identification and label selection.
This decision process is independently carried out on each 6LSR
transited by the lead packets across a 6LSR 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 have been cached.
Though 6LSA modifies flow labels to switch packets, it also preserves
and restores original flow labels prior to destination node delivery.
Before each packet emerges from an ingress 6LSR on a 6LSP, the
original (incoming) flow label is placed in an IPv6 hop-by-hop
options header. An egress 6LSR restores the original flow label and
removes the hop-by-hop options header before forwarding the packet to
non-6LSR domains. Internal 6LSRs within 6LSA domains may ignore but
must not modify the contents of the hop-by-hop options header that
carries the orignial label.
3. Terminology
This section provides a general overview of alphabetically arranged
terms used in this document. Some of these terms are more precisely
defined in the later sections of this document. Most definitions
mirror those provided in RFC 3031 [2] and are applied to the 6LSA
specification as appropriate for consistency.
Chakravorty, et al. Expires April 15, 2007 [Page 6]
Internet-Draft IPv6 Label Switching Architecture October 2006
6LSA a set of nodes that perform 6LSA
routing and forwarding operations
and are in one routing or
administration domain
6LSA egress node 6LSA edge node in its role of
handling traffic as the traffic
leaves a 6LSA domain
6LSA ingress node 6LSA edge node in its role of
handling traffic as the traffic
enters a 6LSA domain
6LSP label switched path, a virtual path,
through a pair or more 6LSRs
6LSR IPv6 label switching router that is
capable of forwarding IPv6 packets
based on FEC attributes
destination node the node which is the destination
of one or more packets
FEC Forwarding Equivalent Class,
collection of IP packets that receive
the same forwarding treatment and are
forwarded over the same 6LSP
Forwarding Table a data structure maintained by each
6LSR that maps incoming IPv6 flow
labels and source and destination
addresses to outgoing labels and
outgoing interfaces
flow sequence of packets identified by
the 3-tuple of source address,
destination address and Flow Label
Flow Label the 20-bit label in the IPv6 header
used for identifying flows
flow merge same as label merging (see below),
when it is applied to flows
label the IPv6 Flow Label which is carried
in the IPv6 packet header which may
represent the packet's FEC; in this
document, the label typically implies
Chakravorty, et al. Expires April 15, 2007 [Page 7]
Internet-Draft IPv6 Label Switching Architecture October 2006
the label from the upstream 6LSR
carried in the Flow Label field
label merging the replacement of multiple incoming
labels with a single outgoing label
label swapping the forwarding operation of looking
in the switching table (to determine
the outgoing label, physical port,
and other data handling information)
and replacing the incoming label
with the outgoing label (if
different from the incoming label)
lead packet the first packet in the flow that
this node has received, not
necessarily the first packet from
the source
NTL packet next-to-the-lead packet, the packet
that arrives at a 6LSA node after
the lead packet of the flow
source node the node that is the source of one
or more packets which all may be
associated with a flow
subsequent packet any packet that arrives at a 6LSA
node after the NTL packet
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.
Chakravorty, et al. Expires April 15, 2007 [Page 8]
Internet-Draft IPv6 Label Switching Architecture October 2006
o IP Transparency End-to-End - By being a Layer 3 protocal and
avoiding encapsulation (as in MPLS) or fragmentation (as in ATM) of
IP, the 6LSA retains the IP transparency end-to-end and provides for
peering in Layer 3.
o No-Extraneous-Label-Binding Option - 6LSA offers the option to
avoid the use of any extraneous labels (labels from other than Layer
3) and may avoid the need for label distribution across the network
o No IPSec Constraints - 6LSA does not typically need to use the
Layer 4 ports 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 fowarding mechanism
such as ATM and as such 6LSA avoids ATM's framgmentation and
reassembly delays and associated header overhead. It also avoids the
need for added signaling and state machine mechanisms to provide 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 Flow Aggregation or Merging - 6LSA allows aggregation of flows
or flow merging if two or more flows are destined for the same
network or non-6LSA domain resulting in benefits of reduced state
maintenance, memory usage and processing.
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. (This is a subject for further work and documentation.)
o Feature Visibility - All of the IPv6 packet header features are
available whlie 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 Transition to 6PE - 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 allowing 6LSA flow labels to be carried over to MPLS labels
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,
Chakravorty, et al. Expires April 15, 2007 [Page 9]
Internet-Draft IPv6 Label Switching Architecture October 2006
say, OC-12.
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 mechanism 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
are generally no delivery or QoS guarantees - 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,
virtual paths or virtual circuits (VCs) which are either permanent or
temporary, 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.
6. 6LSA Basic Components and Their Attributes
In this section, we define the basic components and their attributes
pertaining to 6LSA.
Chakravorty, et al. Expires April 15, 2007 [Page 10]
Internet-Draft IPv6 Label Switching Architecture October 2006
6.1. 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 in an incoming packet is called an "incoming label", and that
in an outgoing packet is called an "outgoing label".
A label is associated with both the flow and FEC. A flow cannot be
identified without a label; the forwarding treatment associated with
a FEC may be identified by the value of the label.
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.2. Flow
A flow is a sequence of packets sent from a particular source node to
a particular unicast, anycast or multicast destination node for which
their special handling by the intervening nodes is desired. The
nature of that special handling might be conveyed to the routers by a
control protocol, such as the resource reservation protocol (RSVP),
Differentiated Services Traffic Engineering (DSTE) mechanism, or by
information within the flow's packets themselves.
A flow is identifed 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 from the source node to the destination
node. 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 labels are also used
for identifying a flow. Further applicable statements are quoted
here from RFC 2460 [3] for clarity. A flow label is assigned to a
flow by the flow's source node. New flow labels must be chosen
(pseudo-)randomly and uniformly from the range 1 to FFFFF hex. 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.
Chakravorty, et al. Expires April 15, 2007 [Page 11]
Internet-Draft IPv6 Label Switching Architecture October 2006
A flow label is assigned to a flow by the flow's source node. New
flow labels must be chosen (pseudo-)randomly and uniformly from the
range 1 to FFFFF hex. 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.
The 6LSRs or destinations are permitted, but not required, to verify
that these 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 (i.e., offset 1 within the IPv6 packet).
The maximum lifetime of any flow-handling state established along a
flow's path must be specified as part of the description of the
state-establishment mechanism, e.g., the resource reservation
protocol or the flow-setup Hop-by-Hop Option. A source must not re-
use 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.
6.3. Forwarding Equivalence Class (FEC)
The Forwarding Equivalence Class (FEC) represents a group of IPv6
packetws that all receive the same forwarding treatment. The
forwarding treatment may be based on one or more attributes
associated with the flow 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 QoS, they are identified by the same FEC.
6.4. Labeled Packet
In 6LSA, a packet that has a label value that a node can bind to a
FEC is called a labeled packet. 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
Chakravorty, et al. Expires April 15, 2007 [Page 12]
Internet-Draft IPv6 Label Switching Architecture October 2006
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.
A 6LSR is so called in this specification because other protocols,
such as the MPLS, identify a label switching router as an LSR which
has different capabilities. This helps avoid ambiguity with the
definition of LSR.
A 6LSR is either an upstream 6LSR or downstream 6LSR. The
relationship means that with respect to a given label binding, a
particular label represents a specific FEC for packets traveling out
of an upstream 6LSR, into a next-hop node or 6LSR, or into a
downstream 6LSR from a previous-hop node or 6LSR.
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
packets in the flow are lost or misdirected.
All lead packets, whether they are the first packet from the upstream
router or 6LSR or not, are treated like they were the first packet of
the flow.
Lead packets have no existing entry in the switching table of the
6LSR. When source nodes are 6LSA nodes, lead packets may carry non-
zero labels.
6.7. Packet Identifier (PID) Field
An identifier, called Packet Identifier (PID) is a field in the
switching table entry. The concept of switching table is later
described in this specification (see the next Section). This field
is updated whenever a packet is received by 6LSR. The PID value
entered is 0 (zero), if the packet is identified as a lead packet, it
Chakravorty, et al. Expires April 15, 2007 [Page 13]
Internet-Draft IPv6 Label Switching Architecture October 2006
is 1 (one) if the packet is a NTL or subsequent packet, that is, it
is not a lead packet.
6.8. Switching Table
A switching table in 6SLA, 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
-- Packet Identifier (PID) Field value of 0 (zero) or 1 (one)
-- 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; this may include
ordering and queuing of the packet prior to its
transmission
The outgoing label entered in the switching table has to be unique so
that the 6LSR is able to identify a unique LSP for the packet. An
exception would be when multiple LSPs are merged. This is discussed
further in the following sections.
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 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 FEC may represent
one or more of the following: Traffic Class, label value, source
address, destination address, TCP/UDP port number, RTP value, one or
more extension headers, special cookie marker in the packet, or
Chakravorty, et al. Expires April 15, 2007 [Page 14]
Internet-Draft IPv6 Label Switching Architecture October 2006
special bit encoding in the body of the message past the protocol
headers. The FEC may also represent packet-forwarding parameters
selected by the network administrator a-priori. For instance, if an
attribute is a 1 Mbps bandwidth allocation to a flow then this
allocation is taken care of in the forwarding treatment of the packet
identified by the binding to the proper FEC.
The binding of a label to a FEC is local to a 6LSR 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.
The attributes of a label binding are configurable or encodable
parameters in the 6LSA. The details of how the attributes are
activated will be presented in a future traffic engineering
specification.
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.
While a flow has a local, per-hop significance, a 6LSP may have
multiple-hop significance within the 6LSA. A 6LSP is identified with
a sequence of 6LSAs, <R1,i,Rn> such that the following
characteristics are applicable:
-- R1, the ingress 6LSR, acquires a label and swaps
it with the current label in packet P unless the
the packet is a lead packet;
-- For all values of i between 1 and n, there is
only one label in each IPv6 packet, P, and this
label value is encoded in the Flow Label field
of P;
-- At no time during transit of P through the network
of 6LSRs within a 6LSP, if the label value is not
bound to a FEC, the FEC can be a best-effort
delivery FEC;
-- For all i, where i has a value between 1 and n+1, Ri
transmits P to R[i+1] by using the outgoing label
in the packet (which is the same as the incoming
label value in case of the lead packet);
Chakravorty, et al. Expires April 15, 2007 [Page 15]
Internet-Draft IPv6 Label Switching Architecture October 2006
-- For all i, between 1 and n inclusive, if a system S
receives and forwards P after P is transmitted by Ri
and before P is received by R[i+1], the forwarding
decision that S makes is not based on the
specifications applicable to 6LSA as identified
in this document; such forwarding decision will
imply that a layer 2 or other non-6LSA decision has
been made outside the scope of this specification;
-- Rn, the egress 6LSR, removes the incoming label and
swaps it with the original label (that the ingress
6LSR received) and forwards the packet out based on
the next-hop address, unless there is peultimate
6LSR label swapping, in which case, Rn may forward
the packet based on the FEC but without binding the
outgoing label to the FEC.
The sequence of 6LSA nodes, that is, the sequence of nodal interfaces
through which P is 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 ingress and egress 6LSRs, 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.
A representative 6LSA layout is shown in Figure 1. In this layout,
labels are encoded in the Flow Label field of the outgoing packets
that are not lead packets, out of the ingress 6LSR, A, the
intermediate 6LSR, B, and removed only at the egress 6LSRs, C, D and
E when the flow of packets is from left ot right. The process is
similar for the flows entering into the four border 6LSRs, A, C, D,
and E in the opposite direction and for intermediate 6LSR. There can
be many ingress, intermediate and egress 6LSRs in a 6LSA.
Chakravorty, et al. Expires April 15, 2007 [Page 16]
Internet-Draft IPv6 Label Switching Architecture October 2006
|L
|
+-+-+
| |
+------------------+ D +---------------+
Non-6LSA | | | |
domain | 6LSA +-+-+ |
| domain | |
| | |
| |L2 (LSP) |
| | |
+-+-+ L1 (LSP) +-+-+ +-+-+
L | +----------------+ | | |
------+ | L2 (LSP) | | L6 (LSP) | | L
----> ------+ A +----------------+ B +-------------+ E +--->
------+ | L3 (LSP) | | | |
| +----------------+ | | |
+-+-+ +-+-+ +-+-+
| | |
| |L2 (LSP) |
| | |
| | |
| +-+-+ |
| | | |
+------------------+ C +---------------+
| |
+-+-+
|
|L
Representation of 6LSPs inside a 6LSA
Figure 1.
Multiple 6LSPs may merge at a 6LSR if they can be identified with the
same FEC and their outgoing route (6LSP) is the same in that they can
terminate on the same next-hop 6LSR interface.
If there are no other egress routers but E, in the representative
configuration shown in Figure 2, the flows coming on three 6LSPs
represented by L1, L2, and L3 into B could be merged and sent out on
one 6LSP represented by L6. In this case, the flows maintain their
identity by their source and destination addresses as well as by the
original labels in the options header extension even if their
outgoing labels are the same on 6LSP. This is also true of the lead
packet flows where labels out of A would be all of 0 (zero) value.
Chakravorty, et al. Expires April 15, 2007 [Page 17]
Internet-Draft IPv6 Label Switching Architecture October 2006
+--------------------------------------+
Non-6LSA domain | |
| 6LSA domain |
| |
| |
| |
+-+-+ L1 (LSP) +-+-+ +-+-+
L | +----------------+ | | |
------+ | L2 (LSP) | | L6 (LSP) | | L
------+ A +----------------+ B +-------------+ E +---
------+ | L3 (LSP) | | | |
| +----------------+ | | |
+-+-+ +-+-+ +-+-+
| |
| |
+--------------------------------------+
Representation of 6LSPs inside a 6LSA
Figure 2.
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 apriori after
packets belonging to a flow have ceased to arrive.
A 6LSP may extend all the way to the end-system if the end-system is
operating within the 6LSA.
9. 6LSA Architectural Functionalities
This section provides fundamental 6LSA functionalities including
label acquiring, label binding to FEC, and label swapping.
a) An ingress 6LSR replaces the incoming label in a
non-lead packet with an outgoing label
establishing a unique 6LSP for one or more
packets in the flow, thus associating, with the
same incoming Flow Label and source and
destination address combination. Each ingress
6LSR ensures there is no duplication of 6LSPs
from itself to the downstream router.
Chakravorty, et al. Expires April 15, 2007 [Page 18]
Internet-Draft IPv6 Label Switching Architecture October 2006
b) An intermediate router receives a flow on a
unique 6LSP.
c) An egress 6LSR replaces the incoming label with
the label from the lead packet before forwarding
the packet out to the destination node or a node
belonging to a non-6LSA domain.
d) To avoid the uncommon event when two flows entering
a 6LSA domain from external sources have the same
label, the Hop-by-Hop Options header is used (for
all flows) to carry the original label and to
identify the start of a new flow. The Hop-by-Hop
Options header contains the original label in its
Data field. A specific Option Type of 70 is used
in the Hop-by-Hop Option header; the Option Data
Length specified is 32. This 32-bit Option Data
field contains the original 20-bit label from
the lead packet with the left most 12 bits as 0
(zero).
e) If a router is a 6LSR, it swaps the label, if it
is not a 6LSR, it lets the flow bypass without
any label changes.
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, a label
has little significance for the downstream 6LSR other than helping it
ascertain the LSP assignment. It has relevance for the upstream 6LSR
which uses it to bind an FEC to the label and then uses the 6LSP to
forward packet. 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 label has any relevance value to the
downstream 6LSR is when the label bindings are distributed across a
given 6LSA domain.
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
but they each still need to be examined by its label. All merged
flow's packets may have distinct source addresses and/or destination
addresses, they all have original flow labels stored in the Hop-by-
Hop Options header. However, once the flows are merged, distinction
between individual flows may not be necessary for packet forwarding.
Chakravorty, et al. Expires April 15, 2007 [Page 19]
Internet-Draft IPv6 Label Switching Architecture October 2006
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 6LSR if it is
the origination point for that flow. The host or 6LSR node then
informs the next-hop, downstream node of this binding via the labeled
IPv6 packet that is transmitted 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
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 6LSR or nodes
Chakravorty, et al. Expires April 15, 2007 [Page 20]
Internet-Draft IPv6 Label Switching Architecture October 2006
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.
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.
This document encourages the use of this model 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.
To avoid duplication of labels between different flows while using
this model, all lead and follow-on packets in a specific flow carry a
unique label generated by the ingress 6LSR in the IPv6 Flow Label
field. The Hop-by-Hop Options header is used by the ingress 6LSR to
contain the original label which is placed in the Data field of the
Hop-by-Hop Option header. A specific Option Type of 70 is used in
the Hop-by-Hop Option header; the Option Data Length specified is 32.
This 32-bit Option Data field contains the original 20-bit label from
the lead packet with the left most 12 bits as 0 (zero).
10.2. Distributed Label Model
The 6LSA allows distribution of label 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 20-bit 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.
The process by which a node binds a label to a FEC are 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.
Chakravorty, et al. Expires April 15, 2007 [Page 21]
Internet-Draft IPv6 Label Switching Architecture October 2006
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.
Details of this model remain to be developed for future
specification.
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
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.
Chakravorty, et al. Expires April 15, 2007 [Page 22]
Internet-Draft IPv6 Label Switching Architecture October 2006
13. Packet Forwarding
Whatever the incoming label, unless the label carries some special
significance because of certain bit arrangement in the label or some
parameters associated with the label that were configured apriori,
the forwarding treatment of the label is of local significance and
decided by the 6LSA node itself. This treatment may or may not be
the same the packet receives in any other node. The 6LSP chosen for
the packet is thus based on the local FEC. The only exception to
this rule may be a case when a label value is assigned globally, by
policy, for example. So when a global label assignment is not used,
that is, global label binding is not used, the 6LSP used for
forwarding packet has significance only for the upstream 6LSR, the
downstream 6LSR only associates the 6LSP with the label in the
packet. The nature of the forwarding treatment and how it is applied
is out of scope for this document.
14. 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 layer 3 non-IPv6 label stacking or layer 2
label stacking for VPNs or such other design.
15. 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
elaborated below. 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.
16. Packet Processing Algorithms
The 6LSA packet processing algorithm refers to handling of packets
that arrive from hosts in the same 6LSA domain or from networks
outside of the 6LSA domain. The 6LSA packet processing provides for
Chakravorty, et al. Expires April 15, 2007 [Page 23]
Internet-Draft IPv6 Label Switching Architecture October 2006
QoS priority handling and forwarding treatment.
If the 6LSA domain is a network connected to one or more non-6LSA
networks that insert labels not known to the 6LSA domain devices
apriori, then the processing is called the Open Network Packet
Processing. This approach can make full use of the Locally Generated
label Model.
If the 6LSA domain is not connected to any external network, such as
would be the case of a closed campus network or a secure network,
where duplication of labels can be avoided through extraneous means,
for example, through grouping of labels across the network as
referred to in the Distributed Label Model, then it is possible to
use a different processing, called here the Closed Network Packet
Processing.
Open Network and Closed Network processing algorithms will be
specified in future drafts. Other packet processing algorithms are
also possible.
17. 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.
18. FEC Mapping
Each FEC may map to a set of flows, node and route characteristics
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.
19. Penultimate 6LSR Label Processing
If the label in a non-lead packet is acquired through the Locally
Generated Label model and not through other means and applied to a
packet in the 6LSR upstream of the penultimate 6LSR, the latter being
the 6LSR one hop upstream of the egress 6LSR, the penultimate 6LSR
may decide to not bind the label to the FEC for this flow but simply
insert it in the packet and forward the packet out since the next hop
is not affected by the absence of any prior label binding. The
egress 6LSR forwards the packet out based on the outgoing route.
This saves processing related to binding at a minimum.
Chakravorty, et al. Expires April 15, 2007 [Page 24]
Internet-Draft IPv6 Label Switching Architecture October 2006
20. 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. The discussion of the values of
such labels are outside the scope of this specification.
21. 6LSP Control: Ordered and Loose
As described in the MPLS label switching architecture [1], some FECs
correspond to address prefixes which are available from dynamic
routing algorithm running in a node. There are two methods in 6LSA
for setting up LSPs for these FECs: Ordered and Loose. The control
of 6LSP is a local function at a 6LSA node. In 6LSA, each FEC is
identified with a set of attributes.
If the traffic in a particular FEC has to follow the same path that
has a specified set of attributes such as bandwidth and other
resources (QoS parameters) etc., then ordered control must be used.
How this ordered control is initiated and maintained is out of the
scope of this document and is an area for further work.
In the loose control, a 6LSR after binding a label to a FEC,
distributes that binding to its label distribution peers more like
the routing algorithms.
Ordered control and loose control are fully interoperable.
22. 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 egress 6LSRs will be able to restore flow labels for
individual flows since the Hop-by-Hop Options header is independent
of the label identifying the merged flow, and a route lookup for the
lead packet of the "first" flow on a merged 6LSP is all that is
required for non-ingress 6LSR's -- a big saving.
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
Chakravorty, et al. Expires April 15, 2007 [Page 25]
Internet-Draft IPv6 Label Switching Architecture October 2006
aggregation may further be decided by the IPv6 packet header Traffic
Class parameters.
23. Route Selection
The method of selecting the proper 6LSP for a particular FEC is
called route selection in the 6LSA and the options the 6LSA allows
are (1) hop-by-hop routing, and (2) explicit routing.
The Hop-by-Hop Option has been described above in Section 9 in which
each node in the 6LSA independently selects the next hop based on a
given FEC. This is very similar to the best-effort routing except
that the forwarding in this mode of 6LSA is FEC driven. For explicit
routing, see Section 24 here below.
24. Explicit Routing using Routing Header Extension
To ensure explicit routing of packets, the 6LSA allows use of IPv6
Routing Header extensions. The Next Header value of 43 is then an
attribute that a given FEC must include. In this case, the label
binding to the FEC represents explicit routing using the Next Header
value. The forwarding treatment a packet gets in a 6LSR comprises
transmitting the packet to the next-hop 6LSR identified in the
destination address field of the packet. The final destination of
the packet in an explicitly routed packet may be outside of the 6LSA
domain.
25. Control
The 6LSA specification requires the Hop Limit value in the packet
header be decremented by 1 (one) in each 6LSR. The 6LSA processing
of Hop Limit remains the same as in conventional IPv6 packet
processing.
26. 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.
Chakravorty, et al. Expires April 15, 2007 [Page 26]
Internet-Draft IPv6 Label Switching Architecture October 2006
How a 6LSA label value is encoded in the ATM VPI/VCI field is outside
the scope of this document.
27. 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
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 a 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.
28. Multicast in 6LSA
IPv6 defines the mutlicast 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 mutlicast 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 mutlicast routing.
The packet is thus forwarded to a next-hop 6LSR through an interface
determined by the FEC attributes related to mutlicast delivery.
29. 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.
Chakravorty, et al. Expires April 15, 2007 [Page 27]
Internet-Draft IPv6 Label Switching Architecture October 2006
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, unwraps the packet and then verifies the
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.
30. Acknowlegements
The author deeply appreciates significant editing contributions made
by Keith Scott (MITRE), and early implementation support provided by
Don Chirieleison (MITRE).
31. 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.
32. Informative Referneces
[1] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
Flow Label Specification", RFC 3697, March 2004.
Chakravorty, et al. Expires April 15, 2007 [Page 28]
Internet-Draft IPv6 Label Switching Architecture October 2006
[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.
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.
Chakravorty, et al. Expires April 15, 2007 [Page 29]
Internet-Draft IPv6 Label Switching Architecture October 2006
Authors' Addresses
Sham Chakravorty
The MITRE Corporation
1575 Colshire Dr.
McLean, VA 22102
USA
Email: schakra@mitre.org
Jeff Bush
The MITRE Corporation
1575 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 April 15, 2007 [Page 30]
Internet-Draft IPv6 Label Switching Architecture October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chakravorty, et al. Expires April 15, 2007 [Page 31]