Internet DRAFT - draft-chakravorty-bcc-flowlabel
draft-chakravorty-bcc-flowlabel
Internet Engineering Task Force J. Bound
Internet-Draft NAv6TF
Expires: October 8, 2005 S. Chakravorty
K. Zhang
The MITRE Corporation
April 9, 2005
Proposal for a New Flow Label Definition
draft-chakravorty-bcc-flowlabel-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 October 8, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The IPv6 header includes a 20-bit Flow Label field. RFC 3697, "IPv6
Flow Label Specification" [1] specified this field and minimum
requirements for using the field. This document first identifies
several issues related to the current Flow Label specification; then
it discusses the limitations of the current specification and the
Bound, et al. Expires October 8, 2005 [Page 1]
Internet-Draft Proposal for a New Flow Label Definition April 2005
need for extending the definition to accommodate emerging
applications and protocols; finally, a new Flow Label specification
is proposed that enables more effective usage of this field.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Issues Concerning the Current Flow Label . . . . . . . . . . . 5
4. New Flow Label Specification . . . . . . . . . . . . . . . . . 7
4.1 Implications . . . . . . . . . . . . . . . . . . . . . . . 9
5. An Emerging Usage for the Flow Label Field . . . . . . . . . . 9
6. Benefits of Flexible Label . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Bound, et al. Expires October 8, 2005 [Page 2]
Internet-Draft Proposal for a New Flow Label Definition April 2005
1. Introduction
The IPv6 header includes a 20-bit Flow Label field. RFC 3697 [1]
specified this field and the minimum requirements required for using
it. This document identifies several issues related to the current
Flow Label specification, it also discusses the limitations of the
current specification and the need for expanding the definition to
accommodate emerging applications and protocols. Additionally, a new
Flow Label definition is proposed that enables more effective use of
this field.
A Flow Label is defined in [1] to be æa sequence of packets sent from
a particular source to a particular unicast, anycast, or multicast
destination that the source desires to label as a flow.Æ It may be
used by a source to label sequences of packets for which it requests
special handling by the IPv6 routers. Such handling could comprise
non-default quality of service or æreal-timeÆ service.
How to identify a flow and assign labels to flows are specified in
RFC 3697[1] as follows:
- A flow is uniquely identified by the 3-tuple of source address,
destination address and a non-zero Flow Label.
- All packets belonging to the same flow must be sent with the same
source address, destination address, and Flow Label.
- Packets that do not belong to a flow carry a Flow Label of zero.
- New Flow Labels must be chosen (pseudo-)randomly and uniformly
from the range 1 to FFFFF hex.
- The Flow Label value set by the source MUST be delivered unchanged
to the destination node(s).
- Nodes keeping dynamic flow state MUST NOT assume packets arriving
120 seconds or more after the previous packet of a flow still belong
to the same flow, unless a flow state establishment method supports
it.
- Source nodes SHOULD assign each unrelated transport connection and
application data stream to a new flow. It MUST ensure that it does
not unintentionally reuse Flow Label values it is currently using or
has recently used when creating new flows.
- To use Flow Labels for classifying and providing special treatment
of traffic, æflow stateÆ needs to be established on all or a subset
of IPv6 nodes on the path from the source to the destination(s). The
Bound, et al. Expires October 8, 2005 [Page 3]
Internet-Draft Proposal for a New Flow Label Definition April 2005
æflow stateÆ should include sufficient information so that pertinent
IPv6 nodes can support required flow-based processing.
In this document, we propose a modified version of the above
specification for the IPv6 Flow Label to add flexibility and ease of
use of the Flow Label especially for Quality of Service (QoS)
delivery.
This specification allows flows to be defined by only the Flow Label
once the uniqueness of the Flow Label has been ascertained for a
given flow between two or more peering routers. Such assertion can
be made by the Flow Label associated with the source and destination
addresses, incoming port or some such other methodologies as
described in [2].
The Flow Label need not be static or a fixed value between the source
and destination, that is, it can be changed enroute provided the
original Flow Label is delivered in the packet at the destination.
Classifying one or more packets in a flow into a class of packets,
called the Forwarding Equivalent Class (FEC) [2], of given
characteristics of QoS, security or some other parameter or a
combination of parameters, is allowed. The flow state can be
established at the start of a flow represented by the Flow Label and
one that can relate to an FEC; the corresponding service can then be
delivered as expected from the flow. Once a flow state has been
established and the packet is bound to an FEC, packet forwarding can
then be based on only the Flow Label, see [2].
This specification of Flow Label thus allows changing the label while
the packet is enroute from the source to the destination as long as
the original label is restored prior to arrival of the packet at the
destination. The Flow Label thus enables processing of flows based
on Flow Label only once the flow has been uniquely identified by a
label and also enables the nodal capability for using label for
packet classification as well as packet forwarding.
2. Background
During the past decade, Internet QoS framework has been built around
the network traffic class based service differentiation and traffic
engineering. DiffServ has emerged as a prevalent Internet QoS
framework that focuses on providing performance differentiation to
different traffic classes. With the æTraffic ClassÆ field in the
IPv6 header that maps to IPv4 DiffServ Code Points (DSCPs), IPv6 can
readily support the QoS framework with the help of the specification
of label provided here. This supports class/priority based traffic
treatment. IPv6 protocol thus provides support for both class based
Bound, et al. Expires October 8, 2005 [Page 4]
Internet-Draft Proposal for a New Flow Label Definition April 2005
or flow based packet classifications as well as specific packet
forwarding treatment related to such classifications.
As of today, the deployment of per-flow based packet forwarding
treatment is rather limited in an IPv6 network. The 20-bit Flow
Label field (whether set by the end applications or not) is ignored
by most network devices. This presents a significant waste of
built-in IPv6 capabilities; the label field could have been
effectively used toward enhancing the overall IPv6 protocol
functionality if certain measure of flexibility were allowed in its
definition and usage.
The primary application of IPv6 Flow Label was to facilitate per flow
resource allocation and/or packet treatment, so that desirable QoS
can be delivered. An IPv6 flow is currently defined on an end-to-end
basis between the source and destination. It was designed based on
an end-to-end fixed label assignment that would signal special
traffic treatment by network devices at the flow level granularity.
Thus, using Flow Labels, traffic could be classified into per
application flows, possibly even to a finer level, e.g., based on
transactions for an application.
The Flow Label field was allowed for mapping to known flows such as
TCP connections, application streams, etc., but no service models or
mechanisms were provided [1].
The IPv6 Flow Label field remained unused and ignored by all for
nearly a decade although use of a similar 20-bit label field in
Multiprotocol Label Switching (MPLS) protocol for similar purposes
received wide implementation support during the same period.
3. Issues Concerning the Current Flow Label
With the current Flow Label definition [1], providing for per-flow
QoS may be a difficult process. We highlight several issues
concerning per-flow QoS support using the Flow Label field.
- The static allocation of Flow Labels defining fixed, end-to-end
flows in large networks is unwieldy at best. If the specification had
allowed for dynamic allocation of Flow Labels as flows were set up
and torn down (or progressed over multiple hops), the network
administrators and/or users would have had the latitude to use one or
more labels (in the same flows) - as and when necessary and for
different purposes. The static characteristic of the Flow Label
allocation end-to-end and its 3-tuple association with source and
destination addresses (which are also static end-to-end) renders the
view that the Flow Label is there to extend the address space into
the Flow Label field. Conversely, one could use the source and
Bound, et al. Expires October 8, 2005 [Page 5]
Internet-Draft Proposal for a New Flow Label Definition April 2005
destination addresses in conjunction with the Traffic Class field to
provide the same services without using the Flow Label at all. There
is no need for a separate static 20-bit field, that has to be used
end-to-end, on top of the 256 bits of address space to identify a
flow.
- Specific flow state establishment methods and the related service
models are out of scope in the current label specification [1].
Devoid of a methodology for establishing a flow or for provisioning
services using established flows meant the Flow Label specification
is incomplete and possibly inadequate toward providing implementation
and deployment direction for efficient use of the label.
- As the Flow Label field carries a static, fixed label generated
by a source host, for a flow to receive requested treatment in the
network, a signaling protocol such as the Label Distribution Protocol
(LDP) (used in MPLS) or Resource Reservation Protocol (RSVP) must be
used to distribute the label binding (packet classification)
information (for this source-based packet classification) to all
other nodes in the network. The current Flow Label specification [1]
does not provide any mechanism for propagating label binding
information into the network which makes the current Flow Label
specification difficult to implement.
- To ensure that flows can be identified uniquely in the network,
the 3-tuple of Flow Label, Source and Destination addresses is used
to define a flow. Given the large address field used by the IPv6
protocol, the memory requirements for maintaining a flow state that
includes two 128-bit addresses and a 20-bit Flow Label (for a total
of 276 bits) can be significant when tens of thousands of flows are
in operation in a network node. Moreover, the operations used for
flow look-ups may also be processing intensive involving multiple
memory fetches per flow in 32-bit or 64-bit machines. This is not
desirable for small or portable devices with limited memory and
processing power.
- In IPv6 packets that must traverse errorùprone or unreliable
links, errors may inadvertently change the Flow Label bits. As the
static Flow Label is to be used end-to-end, the errors may result in
flows that can not be matched to any flow (packet) treatment profile.
The current specification of Flow Label does not address how errored
packets need to be handled or if they can be processed at all in the
error-prone links. Furthermore, errored packets in TCP streams will
fail checksums at the destination host resulting in unnecessary
retransmissions and possible congestion. (On the other hand, flexible
Flow Label as proposed in this document only has local significance
and as such has limited vulnerability.)
Bound, et al. Expires October 8, 2005 [Page 6]
Internet-Draft Proposal for a New Flow Label Definition April 2005
- The fixed label MUST be delivered unchanged to the destination
nodes; this even applies to the zero Flow Label which is used for
labeling packets that are not part of any flow (for nodes that do not
support Flow Label based flows). It is not clear how this requirement
contributes any useful functionality. This constitutes an ideal
mechanism for man-in-the-middle attacks. What is needed to derail an
end-to-end statically defined flow is to simply insert all zeroes in
the Flow Label field thus making the flow a 'non-flow'. The flow
meant for QoS delivery becomes meaningless and could potentially be
harmful to a mission.
- Scalability is another issue with the static, fixed Flow Label
assignment. Static assignments are not considered by their very
nature scalable. For instance, the projected depletion of the fixed
address space in IPv4 has resulted in the adoption of IPv6 (for its
huge address space). Flexibility in the assignment of values to a bit
field as and when needed is considered in general a good idea. This
is true for the Flow Label as well.
To summarize, the current IPv6 Flow Label is little used; its current
specification is confusing. Absent an associated mechanism for label
binding distribution, the specification provides little in way of
functionalities for the IPv6 protocol. Its application in providing
flow based QoS has not been defined, its implementation by network
devices may prove to be expensive and may introduce issues concerning
proper use of the available resources. Its use in the error-prone
media is questionable. It is vulnerable to the man-in-the-middle
attacks.
Finally, the current specification is too restrictive to allow its
wide-spread use; the static allocation of the Flow Label raises
questions regarding its scalability. It is safe to assume that
emerging applications will find it difficult to take advantage of the
current Flow Label specification.
4. New Flow Label Specification
This document proposes limited modification to the current
specification of the Flow Label.
In this new specification, the 20-bit Flow Label in the IPv6 header
is used by a host or network node to label one or more packets of a
flow. In this configuration the label still comprises 20-bits - same
as in the original specification [1], however, an all-zero label can
be used for identifying a specific flow such as for the least
significant, default class of service in the differentiated service
architecture.
Bound, et al. Expires October 8, 2005 [Page 7]
Internet-Draft Proposal for a New Flow Label Definition April 2005
Packet classification uses only the Flow Label to identify which flow
a particular packet belongs to. The use of other information in the
packet header or network node can also be used when necessary to
identify a flow for rendering label binding significance to a flow.
For example, the source and/or destination addresses in the former
case and physical port address in the latter would be examples of
such information.
The Flow Label has local significance - the scope of this could be
limited to a single hop or extended to a whole network domain. A
flow using a unique label can be initiated at a host or any node in a
network. Similarly, a flow can be terminated at the adjacent
downstream node in case of a single-hop flow or can continue for
several hops depending on the extent of use of the original label
binding.
Packets in a flow are processed in a flow-specific manner by the
nodes that have been set up with flow-specific state. The Flow Label
set by the flow source node MUST be delivered unchanged to the flow
destination node(s).
The source node can be a host or a node that generates a flow; this
node can be different from the source host (as identified by the
source address in the packet header) and the destination node can be
a host or node that terminates a flow and can be different from the
destination host (as identified by the destination address in the
packet header).
This specification follows the original specification [1] in that
nodes keeping dynamic flow state MUST NOT assume packets arriving 120
seconds or more after the previous packet of a flow still belong to
the same flow, unless a flow state establishment method in use
defines a longer flow state lifetime or the flow state has been
explicitly refreshed within the lifetime duration.
The use of the Flow Label field does not necessarily signal any
requirement on packet reordering. If an IPv6 node is not providing
flow-specific treatment, it MUST ignore the field when receiving or
forwarding a packet.
To extend the capabilities of the Flow Label, it is proposed that one
bit, the most significant bit (MSB) bit, be specified as follows. In
the following figure, the MSB bit consists of a Label Type (L)
subfield.
The following values are defined for this subfield for a node
receiving a packet from an upstream node or host:
Bound, et al. Expires October 8, 2005 [Page 8]
Internet-Draft Proposal for a New Flow Label Definition April 2005
- 0 hex: this packet is the first packet of a new flow
- 1 hex: this packet is not the first packet of a new flow
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Label with subfield (L)
The binary value of the MSB will make flow merging easier in 6LSA
network [2].
To support 6LSA framework (described below in Section 5) and for
greater scalability of usage, the current fixed Flow Label
specification is extended to allow flexibility in labeling packets.
Labels are not static end-to-end as such the specification
accommodates label swapping in the network nodes. Such a non-static
label is hereafter called ôflexible labelö or flexible label
assignment. In the flexible label assignment, labels can be swapped
in the network nodes of a given network in a 6LSA domain so long as
the original label is reinserted before the flow arrives at the
destination.
4.1 Implications
The proposed modification of the Flow Label field in the IPv6
datagram header has no impacts on hosts and routers that do not
currently support IPv6 Flow Label processing. For other systems,
this modification requires to reduce the label size from 20 bits to
19 bits. This reduces the number of flows from about a million to
about half of that. However, one-half million flows should be
adequate for per-hop QoS delivery in any size network.
5. An Emerging Usage for the Flow Label Field
An architectural framework, called IPv6 Label Switching Architecture
(6LSA) has been proposed [2] to demonstrate how the specification
presented in this document can be used. The architecture allows
network nodes to generate labels locally. The label is then used to
specify flows, bind them to FECs and forward packets at high speed
over the label-derived LSPs.
The architecture includes swapping of labels in a network node, that
Bound, et al. Expires October 8, 2005 [Page 9]
Internet-Draft Proposal for a New Flow Label Definition April 2005
is, the outgoing label replaces the incoming label as the packet
traverses a node. The outgoing label represents the LSP from this
node to the downstream node. The original label is reinstated in the
packet in the 6LSA egress router.
This architecture is meant to provide means for traffic engineering
for QoS delivery. In this model, Flow Label can be changed in a
packet stream. A flow, called pseudo-flow (to avoid conflict with
the current definition [1]), gets identified with a Flow Label as it
is created for each hop, that is, flows have hop-by-hop significance
for a given session and required QoS.
To support IPv6 based label switching, that is, swapping of incoming
label with the outgoing label (the latter mapped to a given FEC) in
the network node is allowed. The label switching is used to set up
label switched paths (LSPs) similar to the MPLS LSPs over which
packets are forwarded after they are bound to a Forwarding Equivalent
Class (FEC).
By using the IPv6 Flow Label value for packet forwarding (and
classification as necessary if not provided by the Traffic Class),
this architecture avoids the link overhead associated with label
distribution that is needed to tie the IPv6 address to a Flow Label.
This layer 3 use of Flow Label for packet forwarding also allows
router peering in layer 3 unlike other contemporary virtual circuit
protocols.
The 6LSA framework [2] is a good example that highlights the needs to
broaden the current definition of the IPv6 Flow Label field. It is
possible that more applications like 6LSA will emerge that can take
advantage of the field.
6. Benefits of Flexible Label
The flexible label has many benefits, an abridged version is provided
here. The 6LSA example [2] shows how these benefits can be realized.
- Supporting a per-hop label assignment mechanism enables
high-speed packet processing through short 20-bit label switching
instead of extremely large 3-tuple, 276-bit flow (identifier) or
128-bit address look-ups. This could signficantly reduce delays for
all delay-sensitive real-time and near-real-time traffic thereby
considerably enhancing QoS delivery.
- In mobile ad-hoc networks, such as in the military networks, the
use of label for packet forwarding provides for fast and flexible
networking for mobile nodes. Once a flow has been set up through any
one of several selected methods such as through association of the
Bound, et al. Expires October 8, 2005 [Page 10]
Internet-Draft Proposal for a New Flow Label Definition April 2005
Flow Label in the first (lead) packet with IPv6 addresses or physical
port or through some other means, all susequent packets in the flow
can be forwarded using the Flow Label. This helps packet forwarding
based soley on the Flow Label and in small, bandwidth constrained
networks this could help eliminate the transmission of the packet
header with each packet beyond the ingress node for packets that are
next-to-lead packets [2]. (This concept is in its early stage of
evaluation at this time.) The process if adopted will save bandwidth
considerably in ad-hoc, mobile links in addition to providing
considerable savings in memory (enormously reduced bit space),
bandwidth (significantly reduced packet header overhead) and
processing (fewer fetches and smaller bit field).
- Labels demarcate per hop label switched paths. Per-hop label
assignment is more robust than end-to-end because the Flow Labels are
assigned hop-by-hop which helps prevent errors from propagating along
the communications path.
- Per hop label assignment allows for using datagram transmission
where QoS requirements can be relaxed or cannot be enforced for
various reasons. This adds another dimension to the use of flexible
label. The packets can still carry the labels but processsing of
packets will not be label based but on conventional routing
algorithms. This could be employed on one or more hops by apriori
design, signaling or ad-hoc configuration control using network
managment tools.
- The flexible label allows ready integration of flows with a local
QoS mechanism as available in a node that can make use of the label -
a node is not dependent on a centrally administered label binding or
packet classification mechanism - this is good for scalability.
Typically, inelastic or preferred elastic class of service rwquires
individual flows to receive preferred treatment. One wat to achieve
this preferred treat ment could through individual Traffic Class
markings and flow-label based forwarding treament of such marked
packets through managed contrl of available resources.
- Allowing local label generation helps eliminate signaling for
distributing labels and save network resources.
- Flexible labeling is efficient because it eliminates lower layer
peering and allows peering between network nodes in layer 3. Flow
Label control plane mechanisms can be tied to one or more layer 3
control plane mechanisms such as an IGP, RSVP, etc., - the latter
helps avoid N2 (n-squared) problems of below-layer 3 virtual
circuits.
Bound, et al. Expires October 8, 2005 [Page 11]
Internet-Draft Proposal for a New Flow Label Definition April 2005
- In mobile ad-hoc networks where links go up and down randomly and
frequently, the end-to-end model of flow establishment and
maintenance is not practical or advisable. The flexible flow labeling
that allows per flow set ups and tear downs, or opting out of flows
where flows are not needed is more desirable .
- The Flow Label as specified here can potentially be used for VPNs
(this is to be addressed in future work).
To summarize, the flexible label as presented in this new Flow Label
specification allows flow labeling dynamically on an as-and-where
needed basis. It is not done statically and on an end-to-end basis
as the current specification does. Flows so definied are not tied to
the flow's source-destination nodal pair but can be specified for any
pair of nodes - nodes connecting by as hort a link as one hop. The
label binding can be totally independent from one hop to another.
Packets can be forwarded using only the label in a flow once the flow
has been set up using this label. There is no restriction as to how
a label is bound to an FEC. It is significant that a flow label is
not only used for packet classification but also for packet
forwarding. Packet forwarding using only the label thus can provide
significant savings in memory, processing and potentially, bandwidth
usage - all of which are very important for mobile networks in which
the nodes are limited by size, weight and power factors and links by
available bandwidth.
The difference between packet forwarding by flow label and packet
forwarding by destination address is that the latter has little or no
mapping to QoS delivery or secured path based delivery, is generally
shortest path based, generally requires route look up (often in the
back plane), is not fast and is not session specific.
The new definition presented here extends the original Flow Label
definition to other purposes such as VPNs (the specification is work
in progress) enhancing both the efficiency and functionality of the
IPv6 protocol.
7. Security Considerations
Since this is related to 6LSA, the considerations here are identical
to those for 6LSA [2]. The flexible Flow Label allows security
association. If the security association (SA) partners are outside
the 6SLA, then there is no effect of this specification on 6LSA
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
Bound, et al. Expires October 8, 2005 [Page 12]
Internet-Draft Proposal for a New Flow Label Definition April 2005
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 or this
specification of the label.
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
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. In both cases, the characteristics of the
flexible label is identical to fixed label,
8. Acknowlegements
The authors deeply appreciate general advice and encouragement
received from inside and outside of Mitre.
9. Disclaimer
The affiliation of the authors 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 author.
10. References
Bound, et al. Expires October 8, 2005 [Page 13]
Internet-Draft Proposal for a New Flow Label Definition April 2005
[1] J. Rajahalme, et al., IPv6 Flow Label Specification, RFC 3697,
March 2004.
[2] S. Chakravorty, IPv6 Label Switching Architecture (6LSA), IETF
ID ædraft-chakravorty-6lsa-01.txtÆ, July 2004.
[3] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification, RFC 2460, December 1998.
Authors' Addresses
Jim bound
NAv6TF
P.O. Box
Hollis, NH 22102
USA
EMail: Jim.bound@hp.com
Sham Chakravorty
The MITRE Corporation
1575 Colshire Dr.
McLean, VA 22102
USA
EMail: schakra@mitre.org
Kevin Zhang
The MITRE Corporation
7515 Colshire Dr.
McLean, VA 22102
USA
EMail: kzhang@mitre.org
Bound, et al. Expires October 8, 2005 [Page 14]
Internet-Draft Proposal for a New Flow Label Definition April 2005
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 (2005). 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.
Bound, et al. Expires October 8, 2005 [Page 15]
