Internet DRAFT - draft-chakravorty-bcc-fec
draft-chakravorty-bcc-fec
Internet Engineering Task Force J. Bound
Internet-Draft NAv6TF
Expires: October 8, 2005 S. Chakravorty
D. Chirieleison
The MITRE Corporation
April 9, 2005
Binding Packets to FECs in 6LSA
draft-chakravorty-bcc-fec-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
IETF Internet Draft "IPv6 Label Switching Architecture (6LSA)" [6LSA]
[2] proposes using the IPv6 Flow Label field to switch packets
through an IPv6 subnetwork. The use of these IPv6 Label Switched
Paths (6LSPs) can provide means for traffic engineering and
potentially increase the speed of packets traversing a routed network
Bound, et al. Expires October 8, 2005 [Page 1]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
with no increase in bandwidth. The 6LSA draft defines two processes:
1) grouping packets with identical forwarding behavior into a
Forwarding Equivalence Class (FEC), 2) forwarding all packets
belonging to an FEC along the same path. The assignment of packets
to an FEC is called binding. The purpose of this document is to
expand on these two processes, discussing specific methods of
performing the required functions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. FEC Construction . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Manual Configuration . . . . . . . . . . . . . . . . . . . 7
4.2 Network Management . . . . . . . . . . . . . . . . . . . . 7
4.3 Pseudoflow . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Label Distribution Protocol . . . . . . . . . . . . . . . 9
5. Binding IPv6 Packets to an FEC . . . . . . . . . . . . . . . . 9
5.1 Manual Configuration . . . . . . . . . . . . . . . . . . . 10
5.2 Algorithmic Binding . . . . . . . . . . . . . . . . . . . 11
5.3 FEC Binding using SNMP . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1 Use of SNMP . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Use of Label Distribution Protocols . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Bound, et al. Expires October 8, 2005 [Page 2]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
1. Introduction
The IETF Internet Draft "IPv6 Label Switching Architecture (6LSA)"
[6LSA] [2] proposes using the IPv6 Flow Label field to switch packets
through an IPv6 subnetwork. The use of these IPv6 Label Switched
Paths (6LSPs) can provide means for traffic engineering and
potentially increase the speed of packets traversing a routed network
with no increase in needed bandwidth.
Label switching in 6LSA, as in MPLS, enables setting up of labeled
paths that can represent different service classes and ensure that
traffic of different such classes flows over these paths. Label
switching may have speed advantages over traditional routing. This
advantage will likely be greater in IPv6 since its address fields are
128 bits long. Next-hop determination using the 20 bit label
proposed in 6LSA should be considerably more efficient than a 128 bit
routing table lookup.
The basic 6LSA draft defines two processes: 1) grouping packets with
identical forwarding behavior into a Forwarding Equivalence Class
(FEC), 2) forwarding all packets belonging to an FEC along the same
path. The assignment of packets to an FEC is called binding. The
purpose of this document is to expand on these two processes,
discussing specific methods of performing the required functions.
Terminology as introduced in the 6LSA draft is reviewed in Section 2
below. Section 3 presents some background information on the 6LSA
design. Section 4 discusses ways to construct FECs. Section 5
describes how packets might be bound to a certain FEC. Section 6
covers security considerations.
2. Terminology
It is intended that this document use the same terminology as the
6LSA draft [2]. This section repeats the relevant definitions from
that document.
6LSA domain a contiguous set of nodes that perform
6LSA routing and forwarding operations
and are in one routing or admin domain
6LSA egress node a 6LSA edge node in its role of handling
traffic as the traffic leaves 6LSA domain
6LSA ingress node a 6LSA edge node in its role of handling
traffic as the traffic enters a 6LSA domain
Bound, et al. Expires October 8, 2005 [Page 3]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
6LSP a label switched path through a pair or
more 6LSRs
6LSR IPv6 label switching router that is capable
of forwarding IPv6 packets based on certain
FEC attributes
label the IPv6 Flow Label which is carried in
the IPv6 packet header and may represent
the packet's FEC
Flow Label the 20-bit label in the IPv6 header used
for identifying flows
label switching a fast forwarding operation allowing
streamlined forwarding of packets by
using labels to identify classes of
data packets which are treated
indistinguishably when forwarding
label switched hop the hop between two 6LSA nodes, on which
forwarding is done using labels
label switched path a virtual path through which all packets
in a flow are routed across a routing or
administrative domain
3. Background
Packets receiving identical forwarding treatment are said to belong
to the same FEC. For example, within a given router, packets that
are sent to the same next-hop over the same link with the same
quality-of-service (QoS) would belong to the same FEC because the
router treats each packet in exactly the same manner. An FEC could
be identified by a tag or label. Thus if an incoming packet is
labeled as belonging to a certain FEC, a forwarding decision can be
made without reference to the packet's destination or to the routing
table. In MPLS, a shim header is needed for the network layer header
to carry this label. A shim header is not required in 6LSA; the Flow
Label is the label. Each router must inform its (upstream) neighbor
of the label value to use to represent each FEC. In MPLS, The
label-to-FEC mapping is passed by means of a label distribution
protocol such as LDP [RFC 3036] or RSVP-TE[RFC 3209].
Once label-to-FEC mappings have been established for each hop along a
given path, unlabeled packets arriving at the first-hop (ingress)
6LSR are classified or bound to an FEC. This classification can be
Bound, et al. Expires October 8, 2005 [Page 4]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
based on a variety of characteristics including destination address,
source address, Traffic Class, TCP/UDP port, etc. At each subsequent
hop, the forwarding decision can be made solely by examining the
incoming label without further reference to the packet's header or
contents.
The 6LSA uses the Flow Label field in the IPv6 header to represent
the FEC of the packet. Constraints on using the IPv6 Flow Label
field are described in RFC 3697, IPv6 Flow Label Specification [RFC
3697]. Among other considerations, this document requires that the
Flow Label be passed unchanged from source to destination. The 6LSA
Label Switching Routers (6LSRs), however, should be free to make use
of this field. If the source host has left the field set to zero, an
egress 6LSR, when it forwards a packet to a non-6LSA router, can set
the Flow Label back to zero thus restoring it to its original state.
In the 6LSA architecture, each port on a 6LSR would be configured as
an "edge" (ingress/egress) port or a "network" port. These routers
could include non-6LSR ports as well, but such configurations are
beyond the scope of this document.
Packets eligible for 6LSA treatment that arrive at an edge port of a
6LSR are bound to an FEC. The FEC is represented by a non-zero value
inserted in the IPv6 Header Flow Label field. Of course if a packet
arriving at a 6LSR ingress port is to be forwarded out another edge
(egress) port on the same 6LSR, the Flow Label field need not be
changed. Therefore the 6LSA switching technique applies only to
packets being forwarded out network ports on the 6LSR. This also
provides the flexibility of IP routing as well as label switching of
packets.
Because of the requirement to maintain the integrity of the Flow
Label field, the 6LSA switching technique can only be applied to
packets arriving at an edge port with their Flow Label field set to
zero. In future work on 6LSA, more generalized treatment of packets
that arrive with non-zero Flow Label will be presented. In the
simplest design, we assume that the network can be configured so that
only the former packets with zero label arrive at 6LSR edge ports.
More involved techniques for separating and marking 6LSA-eligible
packets arriving at edge ports are discussed in Section 5.
A packet arriving at a network port on a 6LSR must either have a 0
Flow Label field (indicating the first packet in a new flow), have
its Flow Label field set by the upstream (previous-hop) router as an
indication of the packet's FEC (for the current router), or be marked
in some way as ineligible for 6LSA-treatment. If the packet is
eligible for 6LSA treatment and is being forwarded out an edge
(egress) port, the Flow Label is set to zero. If an eligible packet
Bound, et al. Expires October 8, 2005 [Page 5]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
is being forwarded out a network port, the Flow Label field is
unchanged if it is zero (indicating a new flow to the next-hop) or
set to the value corresponding to the packet's FEC at the next-hop
LSR.
The remainder of this document will focus on two questions:
1) How does a 6LSR construct FECs?
2) How does a 6LSR bind packets to an FEC?
4. FEC Construction
For the purposes of this discussion, an FEC is viewed as a list of
one or more addresses or prefixes with their associated Traffic Class
value for QoS or precedence. Packets destined for any of the
addresses/prefixes in the list (with the specified QoS if applicable)
will be forwarded in exactly the same way, e.g., they will be sent
out the same port with the same data link encapsulation, and the same
outgoing label. The simplest instance of an FEC is a single IPv6
address with default forwarding precedence. A significantly more
complicated FEC might be a list of all routing table entries with the
same next-hop. The forwarding treatment for a set of packets is
represented by a forwarding data structure. This structure contains
the required forwarding information including:
1) PacketÆs next-hop
2) Outgoing interface
3) Outgoing label
4) Data link encapsulation
5) Precedence or outbound queuing information.
In general, IPv6 packets will arrive at a 6LSR network port with a
non-zero label in the header (unless it is the first packet in the
flow). In order to determine the proper forwarding treatment for the
packet the 6LSR will consult a switching table which maps inbound
labels to the appropriate forwarding data structure. The forwarding
structure will define how to send the packet to its next hop
including what outbound label to use if the outgoing port is not an
edge port. Multiple switching table entries can refer to the same
forwarding data structure. Similarly, a single incoming label can
map to multiple forwarding entries to permit load balancing.
Bound, et al. Expires October 8, 2005 [Page 6]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
There are several methods that might be used to populate the
forwarding data structure list and switching table. Those that will
be discussed here are:
1) Manual configuration
2) Network management (SNMP)
3) Inference from incoming packets
4) Label distribution protocol
4.1 Manual Configuration
Fixed paths through a 6LSA domain (tunnels) can be pre-computed and
loaded into a 6LSR by manual or semi-automatic means. For example, a
configuration file containing the switching table could be downloaded
into a device from a central distribution point. While not very
practical for large systems in large networks, this approach might be
useful in certain cases. The syntax of the commands needed to
configure the device are of course implementation dependent and have
to be consistent with the overall command structure of the device.
4.2 Network Management
With the definition of appropriate MIBs, SNMP could be used to set up
the forwarding data structures and the switching table for a 6LSR.
Again, this technique would be most useful for setting up tunnels
through a 6LSA domain with fairly static links. The information that
would have to be supplied to the router would include the contents of
the forwarding data structure for each FEC being configured using the
MIB as well as one or more switching table entries mapping an
incoming label to that data structure. Information contained in the
forwarding data structure would have to be sufficient to accomplish
forwarding to the next-hop 6LSR. This would include outgoing port,
outgoing label and data link encapsulation if required. Each of
these data structure elements could be defined by an entry in a MIB
table. Likewise, the contents of the switching table could be
specified by entries in a second MIB table.
An example of a MIB for configuring MPLS LSPs is presented in
ôMultiprotocol Label Switching (MPLS) Label Switching Router (LSR)
Management Information Baseö (RFC 3813). The MIB(s) necessary to
implement this approach in the 6LSA will be defined in a separate
document.
Bound, et al. Expires October 8, 2005 [Page 7]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
4.3 Pseudoflow
If the FECs are limited to a single element consisting of one
address, the incoming label can be distributed piggy-backed onto a
data packet. With this approach, a 6LSR forwarding packets out a
network port selects an unused label from its own label space. The
label space can be per-platform or per-port (if the next-hop router
can unambiguously determine the label space of the packet it
receives, e.g., on a point-to-point link). The chosen label is added
to the forwarding data structure as the outgoing label for the FEC
and is also inserted into the Flow Label field of the outgoing
packet. The packet is then forwarded per the information contained
in the forwarding data structure, i.e., along the routed path. When
the packet is received at the next-hop router, that 6LSR can locate
its own forwarding data structure for the packet by means of the
packetÆs destination address. The label in the incoming packet is
used to create the switching table entry associating that label with
the forwarding data structure. The forwarding treatment for
succeeding packets can then be determined directly through a table
lookup using the incoming label as an index. (In future work on
6LSA, it will be shown how only the label can be used for forwarding
packets instead of the whole IP Header with each packet.)
Similarly, if the FEC is limited to specific Traffic Class values,
the incoming labels or one generated locally in the router could be
mapped to the Traffic Class. Other ways to infer the FECs would be
from the values in specific Extension Header fields. Details of such
methods will be presented in future work.
As explained in the 6LSA draft, the receiving router would typically
set up a forwarding data structure when the lead packet for the flow
to a particular destination first appears. According to the
specification, the lead packet for the flow should arrive at a 6LSR
port with a zero label. The zero label is in general a signal that a
new flow has arrived. If, however, the lead packet is lost and the
first packet to arrive has a label, the router can set up the
forwarding entry for the flow at that time using the accompanying
Flow Label.
With the arrival of the first labeled packet for the flow, the 6LSR
can set up the table entry associating the input label with the
forwarding data structure. The reason that the FEC is in general
limited to a single address is that the upstream 6LSR which assigns
the label has no knowledge of how the next-hop 6LSR will forward the
packet. For example, if the upstream 6LSR were to assign the same
label to all packets destined for a particular prefix, the next-hop
6LSR would have to check the routing table each time it receives a
packet with that label in order to assure that the forwarding rules
Bound, et al. Expires October 8, 2005 [Page 8]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
for the entire prefix are identical.
4.4 Label Distribution Protocol
This is the approach taken initially by MPLS. Several special
protocols have been defined to distribute MPLS labels including LDP,
Constrained Routing LDP [RFC 3212], and RSVP-TE.
Regardless of the process used to set up the 6LSA switching table,
any two adjacent 6LSRs must agree on the meaning of the labels they
exchange. In particular, the label on an incoming packet must
unambiguously define the forwarding behavior for the recipient of the
packet. The local configuration and network management approaches
mentioned above use an external agency to make adjacent routers aware
of the labels' meaning. The label distribution protocol approach
allows one router to simply inform its neighbor what a label means.
In LDP, for example, two MPLS routers establish a session between
themselves. One of the routers can then send a Label Mapping message
to its peer informing the peer of the incoming label that will map to
one of the sending router's FECs. This message would correspond to
one entry in the Incoming Label Map (ILM) since it relates an
incoming label to the Next Hop Label Forwarding Entry (NHLFE) that
defines the forwarding behavior for the FEC.
One of the existing label distribution protocols could be used
between two 6LSRs with a minimum of modification to the protocol.
This specification allows use of one or more label distribution
protocols to provide FEC values to the 6LSR domain.
5. Binding IPv6 Packets to an FEC
The process of binding IPv6 packets to FECs involves examination of
the packet header and/or contents for the characteristics that
determine membership in a certain FEC. In general, that requires
specification of a set of rules that determine the appropriate FEC
assignment for various types of packets.
Packets should be bound to an FEC at 6LSR edge (ingress) ports.
There may be several approaches to the establishment of the binding
rules. Three are discussed here:
Bound, et al. Expires October 8, 2005 [Page 9]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
1) Manual Configuration
2) Algorithmic Binding
3) Network Management
5.1 Manual Configuration
Binding rules can be established by manual means either through a
Command Line Interface (CLI) or by using an externally generated
configuration file. The syntax of the FEC binding portion of the CLI
or configuration file would have to be implementation-dependent in
order to be consistent with the other router functions.
As an example, consider a very simple packet classification scheme.
There are two levels of service, priority and standard. Packets
originating from a pre-configured set of addresses are given priority
service. All others receive standard service. Also assume a very
simple policing function, e.g., no more than 10% of incoming packets
(over some pre-defined time period) may be given priority service.
Packets exceeding this limit are given standard service.
The packet classification and traffic conditioning operations
described above are performed at a 6LSR edge port. For incoming
packets to be eligible for 6LSA forwarding, the IPv6 Flow Label field
in packets appearing at a 6LSR edge port may be set to zero. Packets
with non-zero Flow Labels may be given default treatment. Thus, at
the edge port, packets are divided into 3 groups:
1) Priority 6LSA packets
2) Standard 6LSA packets
3) Non-6LSA packets
In this example, a 6LSA network is considered to be a ôDifferentiated
Services Domainö in the sense of the applicable RFC ôDefinition of
the Differentiated Series Field (DS Field) in the IPv4 and IPv6
Headersö[RFC 2474]. In this specification, a Differentiated Services
Domain is defined as ôa contiguous portion of the Internet over which
a consistent set of differentiated services policies are administered
in a coordinated fashionö. Packets must enter and exit the domain
through a 6LSR edge port. Within the domain, packets are forwarded
between ônetworkö ports of 6LSRs.
Once a packet is classified, the edge port can exercise its
Differentiated Services (DS) marking function by setting the Traffic
Bound, et al. Expires October 8, 2005 [Page 10]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
Class byte (DS Field) to the appropriate value. Once a packet is
marked, downstream 6LSRs will know the correct forwarding behavior
with respect to precedence. Also, downstream 6LSRs will know to
leave the Flow Labels of non-6LSA packets unchanged. For Priority
and Standard class 6LSA packets, the edge router can assign an
outgoing label based on destination and precedence.
As the marked packets arrive at successive 6LSR network ports, their
forwarding class can be obtained from the Traffic Class byte in the
header. The outgoing label (for outbound network ports) is assigned
based on destination and Traffic Class so. This achieves the goal of
having forwarding behavior solely defined by incoming label.
The CLI or configuration file command syntax must be adequate to
specify a variety of parameters including but not limited to:
1) Number of QoS/precedence levels
2) Differentiated Services Code Point (DSCP) or Traffic Class for each service level
3) Traffic policing parameters
4) Label assignment criteria
5.2 Algorithmic Binding
The algorithm(s) for assigning packets to FECs can be coded into the
6LSR edge port packet handling software at the time it is designed.
This code segment might consist of one or more filters that examine
incoming packets for certain characteristics, e.g., TCP/UDP port
number. The presence or absence of these characteristics would
result in the packet being assigned to certain predetermined FECs.
A simple example would be the case where FECs consist of single
destination addresses. Edge port behavior could be coded such that
each time a packet arrives for a new destination, a new FEC is
created. An unused label is chosen to represent this FEC and the
packet is forwarded.
The obvious disadvantage of this approach is its inflexibility.
Network managers would not be able to change the assignment of
packets to FECs. In some cases, however, the added overhead and
complexity of providing a more flexible approach might not be
justified.
Bound, et al. Expires October 8, 2005 [Page 11]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
5.3 FEC Binding using SNMP
The algorithm(s) for assigning packets to FECs can be coded into the
6LSR edge port packet handling software at the time it is designed.
This code segment might consist of one or more filters that examine
incoming packets for certain characteristics, e.g., TCP/UDP port
number. The presence or absence of these characteristics would
result in the packet being assigned to certain predetermined FECs.
A simple example would be the case where FECs consist of single
destination addresses. Edge port behavior could be coded such that
each time a packet arrives for a new destination, a new FEC is
created. An unused label is chosen to represent this FEC and the
packet is forwarded.
The obvious disadvantage of this approach is its inflexibility.
Network managers would not be able to change the assignment of
packets to FECs. In some cases, however, the added overhead and
complexity of providing a more flexible approach might not be
justified.
6. Security Considerations
Security considerations for the use of the Flow Label switching
method itself are discussed in the architecture document [6LSA]. To
summarize, for Security Associations operating in the transport mode,
only the packet payload is encrypted and hence fields in the IPv6
header, i.e., the Flow Label field, are not affected. In the tunnel
mode, the IPv6 packet is encapsulated in an outer packet which
includes a new header. In this case, the Flow Label is not accessed
until the packet reaches the end point of the Security Association
and is unwrapped. Hence the 6LSA has no impact on security in this
mode either.
Techniques for setting up forwarding entries and FEC bindings have
been described in this document. Those techniques involving network
protocols have the same security considerations as the protocols
themselves. Specific cases are outlined below.
6.1 Use of SNMP
SNMP has been discussed as a possible approach to defining FECs and
FEC bindings. If this technique is used, the MIBs (yet to be
defined) could be used to set up 6LSPs that deliver traffic to
improper destinations. This situation is discussed in the document
that defines the FTN MIB [RFC 3814]. The authors of this document
encourage the use of SNMPv3 which has security features built in to
avoid unauthorized Set operations on MIB tables.
Bound, et al. Expires October 8, 2005 [Page 12]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
6.2 Use of Label Distribution Protocols
This document has discussed the use of a label distribution protocol
for defining label-to-FEC mappings in 6LSRs. Specific security
considerations would depend on the details of the protocol selected.
An example of the security consequences resulting from the use of
such protocols can be found in the LDP specification [RFC 3036].
This document points out that the security requirements of label
distribution protocols are the same as those of routing protocols.
The LDP specification states further that "To avoid label spoofing
attacks, it is necessary to ensure that labeled data packets are
labeled by trusted LSRs and that the labels placed on the packets are
properly learned by the labeling LSRs."
7. References
1. Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels, BCP 14, RFC 2119, March 1997
2. [6LSA] Chakravorty, S., IPv6 Label Switching Architecture (6LSA),
draft-chakravorty-6lsa-01.txt, January 2005.
3. [RFC 3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, LDP Specification, RFC 3036, January 2001.
4. [RFC 3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC
3209, December 2001.
5. [RFC 3697] Rajahalme, J., Conta, A., Carpenter, B., and S.
Deering, IPv6 Flow Label Specification, RFC 3697, March 2004.
6. [RFC 3212] Jamoussi, B., et. al, Constraint-Based LSP Setup using
LDP, RFC 3212, January2 002.
7. [RFC 2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers, RFC 2474, December 1998.
8. [RFC 3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To
Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information
Base (MIB), RFC 3814, June 2004.
9. [RFC 3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)
Management Information Base (MIB), RFC 3813, June 2004.
Bound, et al. Expires October 8, 2005 [Page 13]
Internet-Draft Binding Packets to FECs in 6LSA April 2005
8. Acknowlegements
The authors deeply appreciates Mitre management support for
implementation of this protocol.
9. Disclaimer
The authors' affiliation with HP and the MITRE Corporation is
provided for identification purposes only, and is not intended to
convey or imply either HP's or MITREÆs concurrence with, or support
for, the positions, opinions or viewpoints expressed by the authors.
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
Don Chirieleison
The MITRE Corporation
7515 Colshire Dr.
McLean, VA 22102
USA
EMail: donc@mitre.org
Bound, et al. Expires October 8, 2005 [Page 14]
Internet-Draft Binding Packets to FECs in 6LSA 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]
