[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/