Network Working Group K. Shiomoto(NTT)
Internet Draft R. Rabbat(Fujitsu)
Updates: MPLS-HIER, 3477 A. Ayyangaer(Juniper Networks)
Proposed Category: Proposed Standard A. Farrel(Old Dog Consulting)
Expires: April 2006 October 17, 2005
Advertisement of hierarchical and stitchable LSPs as TE Links
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt
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.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 17, .
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Shiomoto Expires April 17, 2006 [Page 1]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
Abstract
This document addresses topics related to hierarchical and stitched
Label Switched Paths (LSPs). It describes extensions to allow an
egress to identify that an LSP will be used as a dynamically signaled
Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In
addition, the document addresses the issue of how to indicate that an
LSP should be advertised as a TE link into a different instance of
the control plane and how to identify the instance that should be
used.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction and Problem Statement.............................3
1.1. LSP Hierarchy.............................................3
1.2. Problem Statement.........................................3
1.3. Current Approaches and Shortcomings.......................5
1.4. Contents of This Document.................................5
2. Proposed Solution..............................................6
2.1. Control Plane Instance Identification.....................6
2.2. LSP_TUNNEL_INTERFACE_ID Object............................7
2.2.1. Unnumbered link......................................7
2.2.2. IPv4 numbered link...................................8
2.2.3. IPv6 numbered link...................................9
2.2.4. Unnumbered link with target control plane instance
identifier..................................................9
2.3. TLVs.....................................................10
2.4. LSA advertisement........................................10
3. Applicability Statement.......................................11
4. Backward Compatibility Considerations.........................11
5. Security Considerations.......................................12
6. IANA Considerations...........................................12
7. References....................................................12
7.1. Normative References.....................................12
7.2. Informative References...................................13
Author's Addresses...............................................13
Intellectual Property Statement..................................14
Disclaimer of Validity...........................................14
Copyright Statement..............................................15
Acknowledgment...................................................15
Shiomoto Expires April 17, 2006 [Page 2]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
1. Introduction and Problem Statement
1.1. LSP Hierarchy
LSP hierarchy has been developed to improve the scalability of
Generalized Multi-Protocol Label Switching (GMPLS) by aggregating
LSPs into a hierarchy of such LSPs [HIERAR].
The operation is as follows for a numbered Forwarding Adjacency:
1. The ingress signals the LSP using a /31 sender address that it
allocates.
2. The egress sets up the LSP.
3. The ingress then forms a Forwarding Adjacency (FA) out of that LSP
by advertising it as a Traffic Engineering (TE) link; toward that
end, it uses the routing protocol (OSPF/ISIS) to advertise the TE
link using the /31 address. The head-end address of the FA-LSP is
specified in the IPv4 tunnel sender address in the Sender Template
Object of the FA LSP.
4. When the egress receives the advertised TE link information, it
checks the Link-ID address of the TE advertisement against its own
TE Router ID. If it matches its own TE Router ID, the egress
checks the advertising router ID of the TE advertisement against
the ingress addresses of LSPs for which it is the egress and finds
the address match with the advertising router ID of the TE
advertisement.
5. The egress then advertises the TE information setting the
advertising TE Router ID in the Link-ID and the assigned /31
address in the local interface address.
Nesting of LSPs originated by other LSRs into that LSP can be
achieved by using the label stack construct.
1.2. Problem Statement
The extensions described in this document are intended for
dynamically signaled bi-directional Forwarding Adjacency LSP (FA-LSP).
In order that the egress of an LSP can advertise the LSP as a TE link
it needs to know that such an advertisement is desirable, and it also
needs to know the TE Router ID of the ingress LSR (Please recall that
Shiomoto Expires April 17, 2006 [Page 3]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
the Router ID of the other end of the link is set in the Link-ID sub-
TLV of the Link TLV of TE Opaque-LSA [RFC3630]). For the numbered FA,
there is no place in the RSVP signaling messages of FA LSP to carry
the TE Router ID of the ingress LSR. Therefore the egress LSR has to
wait to receive the TE advertisement by the ingress LSR to learn the
TE Router ID of the ingress node until it advertises the FA as
described in Section 1.2.
Different methods for the exchange of both numbered and unnumbered
endpoints are defined in [HIERAR] and [RFC3477] respectively. For
unnumbered TE links this information is available using the
mechanisms in [RFC3477]. If the LSP_TUNNEL_INTERFACE_ID object is
present, it indicates that the LSP is to be advertised as a TE link,
and it contains the TE Router ID of the ingress LSR. However, for
numbered TE links, the mechanism in [HIERAR] does not provide this
information. Since the LSP_TUNNEL_INTERFACE_ID object is not used
there is no trigger for TE link advertisement on the egress.
Related to the above problem, a few key observations are worth
noting:
1. The concept of an FA is applicable only when an LSP is both
created and used as a TE link by exactly the same instance of the
GMPLS control plane. [HIERAR] did not consider scenarios where an
LSP is created (and maintained) by one instance of the GMPLS
control plane, and is used as a (TE) link by another instance of
the GMPLS control plane. This leaves open the question of
advertising a TE link into a different instance of the control
plane as is needed in multi-region/multi-layer networks [MRN].
[HIERAR] also does not address how to identify which instance of
the control plane should be used.
2. [HIERAR] provides a way to exchange numbered identifiers for the
TE link, but this does not serve as a trigger for TE link
advertisement.
3. It is important to note that an LSP that is set up in a GMPLS
transport network then advertised as a TE link in the MPLS data
network is NOT an FA-LSP.
Shiomoto Expires April 17, 2006 [Page 4]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
4. When an egress checks the address of the advertised TE link to
find the LSP sender (Recall step (4) as described in section 1.1),
it must check the Link-ID address of all received TE
advertisements against its own TE Router ID. If it matches its
own TE Router ID, the egress checks the advertising router ID of
the TE advertisement against the ingress addresses of all LSPs for
which it is the egress. It is an assertion of the authors that
this method is not scalable due to the amount of processing needed
for all the TE Link State Advertisements (LSAs).
1.3. Current Approaches and Shortcomings
[RFC3477] provides a mechanism to exchange unnumbered identifiers for
the TE link during H-LSP establishment, and this can be used as a
notification to the egress that the LSP will be used as a TE link.
So for unnumbered TE links, there is a well-defined trigger available.
The use of unnumbered TE links may be arguably more sensible,
especially in the case of large networks. Some operators though
prefer to consistently use numbered TE links for both static and
dynamic TE links in their networks. In case of numbered TE links,
however, there is no such available trigger for the egress to know
that an H-LSP should be advertised as a TE link.
In addition, using unnumbered TE links still does not address the
issue of advertising TE links into different layers, nor is it
sufficient for dynamic bundling.
The Link Management Protocol (LMP) [LMP] could possibly be run on
remote adjacencies between the endpoints of the LSP. LMP peer
discovery is required for dynamic LMP peering. In addition, remote
LMP adjacency remains unproven. Last, it would require that all
layers/regions in an MRN network to run LMP. This may not be the
case and would put undue burden on the network operator to deploy
fully a new protocol.
1.4. Contents of This Document
This document provides a consolidated way of exchanging TE link
identifiers when an LSP is established through signaling. It also
provides a mechanism to allow the ingress to control whether, and
into which control plane instances, an LSP is advertised as a TE link
by the egress. The proposed mechanism applies equally to Hierarchical
LSPs (H-LSPs) and Stitchable LSPs (S-LSPs).
Shiomoto Expires April 17, 2006 [Page 5]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
The method described below extends the method described in [RFC3477],
which is applied for an unnumbered TE link represented as an FA.
2. Proposed Solution
The following method allows the ingress and egress LSR to exchange
the link address or link identifier (including the node ID) of the
other end of a TE link for numbered and unnumbered TE link. It is an
extension of the procedures defined in [RFC3477] for unnumbered TE
links.
If a head-end LSR that originates an LSP intends to advertise this
LSP as a TE link in IS-IS or OSPF [LSP-HIER], the head-end LSR MUST
allocate an address or identifier to the TE link (just like for any
other TE link). Moreover, the Path message used for establishing the
LSP that will be used to form the TE link MUST contain the
LSP_TUNNEL_INTERFACE_ID object (as extended and described below),
with the interface address or identifier allocated by the head-end
LSR.
If the Path message for the H-LSP/S-LSP contains the
LSP_TUNNEL_INTERFACE_ID object, then the tail-end LSR MUST allocate
an address or identifier to that TE link (just like for any other
numbered or unnumbered TE link). Furthermore, the Resv message for
the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the
interface address or identifier allocated by the tail-end LSR
In all cases where an LSP is to be advertised as a TE link the Tunnel
Sender Address in the Sender Template Object MUST be set to the TE
Router ID of the head-end LSR. We should note that this is a change
from the method described in [HIER].
Once the addresses or identifiers for the LSP have been exchanged
using these signaling extensions, and once the LSP has been
successfully established the head-end and tail end SHOULD advertise
the LSP as a TE link using the addresses/identifiers exchanged. Once
the TE link advertisement has been flooded it is available for use in
path computation and LSP signaling just like any other TE link.
2.1. Control Plane Instance Identification
The mechanism described so far allows a head-end LSR to indicate that
an LSP is to be used as a TE link and allows the head-end and tail-
end LSRs to exchange addresses or identifiers for that TE link,
during LSP setup.
Shiomoto Expires April 17, 2006 [Page 6]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
However, it is also necessary to indicate into which instance of the
control plane the advertisement should be made. This first requires
that a 32-bit identifier is assigned to each of the various control
plane instances within a network, and that head-end and tail-end LSRs
have the same understanding of these numbers. This is a management
configuration exercise outside the scope of this document.
Once these numbers have been assigned, they MAY be signaled as
additional information in the LSP_TUNNEL_INTERFACE_ID object to
indicate to which instance of the control plane the object applies.
The control plane instance identifier value of zero is reserved to
mean indicate that the TE link SHOULD be advertised into the same
instance of the control plane as was used to establish the LSP. That
is, a value of zero means that an FA is to be established.
2.2. LSP_TUNNEL_INTERFACE_ID Object
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class
number of 193, which designates that a node that does not understand
the object SHOULD ignore the object but forward it, unexamined and
unmodified, in all messages resulting from this message.
[RFC3477] defines one class type to indicate an unnumbered interface
identifier. This document defines three new class types as follows.
C-Type Meaning Reference
---------------------------------------------------------------------
1 Unnumbered interface identifier [RFC3477]
2 (TBD by IANA) IPv4 interface identifier with target 2.3.2
3 (TBD by IANA) IPv6 interface identifier with target 2.3.3
4 (TBD by IANA) Unnumbered interface with target 2.3.4
Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type
values 2, 3 or 4 MAY appear in any one Path or Resv message, in which
case, each MUST have a different value for the Target Control Plane
Instance field. A Path or Resv message MUST NOT contain more than
one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and
if such an object is present, other instances of the object with any
other C-Type value MUST NOT have Target Control Plane Instance set to
zero.
2.2.1. Unnumbered link
The unnumbered link identifier defined by [RFC3477] is not changed by
this document. Its usage also remains the same. That is, when
Shiomoto Expires April 17, 2006 [Page 7]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
present in a Path message it indicates that the LSP being established
SHOULD be advertised by the egress LSR as a TE link, and that
unnumbered link identifier is the ingresses identifier for the TE
link.
Note that since this form of the object does not contain a target
instance identifier it cannot identify a specific instance of the
control plane into which this TE link should be advertised. Thus,
when C-Type 1 is used, the TE link SHOULD be advertised only into the
same instance of the control plane as was used to create the LSP.
That is, the use of C-Type 1 is unchanged from [RFC3477] and is used
to create an unnumbered Forwarding Adjacency.
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface ID"
for that LSP; in the latter case, we call it the "Reverse Interface
ID" for the LSP.
Only one instance of this object with C-Type 1 may be present on a
Path or Resv message.
2.2.2. IPv4 numbered link
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined
to carry an IPv4 numbered interface address and to indicate into
which instance of the control plane the consequent TE link should be
advertised.
The format of the object is as shown below.
C-NUM = 193, C-Type = 2(TBD by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Interface Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Control Plane Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shiomoto Expires April 17, 2006 [Page 8]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface
Address" for that LSP; in the latter case, we call it the "Reverse
Interface Address" for the LSP.
2.2.3. IPv6 numbered link
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined
to carry an IPv6 numbered interface address and to indicate into
which instance of the control plane the consequent TE link should be
advertised.
The format of the object is as shown below.
C-NUM = 193, C-Type = 3(TBD by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Control Plane Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface
Address" for that LSP; in the latter case, we call it the "Reverse
Interface Address" for the LSP.
2.2.4. Unnumbered link with target control plane instance identifier
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined
to carry an unnumbered interface identifier and to indicate into
which instance of the control plane the consequent TE link should be
advertised. This does not deprecate the use of C-Type 1, but extends
its utility.
Shiomoto Expires April 17, 2006 [Page 9]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
The format of the object is as shown below.
C-NUM = 193, C-Type = 4(TBD by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Control Plane Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface ID"
for that LSP; in the latter case, we call it the "Reverse Interface
ID" for the LSP.
2.3. TLVs
All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the following
format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (16 bits) | Length (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field contains the total length of the TLV including the
Type and Length fields in bytes. A value field whose length is not a
multiple of four MUST be zero-padded so that the TLV is four-byte
aligned.
2.4. LSA advertisement
The ingress and egress LSRs MAY advertise link state associated with
TE links created as described above. The link state may be
Shiomoto Expires April 17, 2006 [Page 10]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
advertised in either the same control plane instance as used to
compute and signal the path for the LSPs that support the TE links,
or another control plane instance. In the former case, the address
space for the link state MUST be the same as that used to establish
the LSPs. In the latter case, the address space for the link state
MAY be different, which means that addresses already allocated in the
control plane instance used to establish the LSPs MAY be used by the
advertised TE link without any ambiguity.
In the routing protocol the TE Router ID of the ingress LSR is taken
from the Tunnel Sender Address in the Sender Template object. It is
assumed that the ingress LSR knows the TE Router ID of the egress LSR
since it has chosen to establish an LSP to that LSR and plans to use
the LSP as a TE link.
The link interface addresses or link interface identifiers for the
forward and reverse direction links are taken from the
LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages
respectively.
Address overlap checking for these objects MUST be turned off in case
that the LSA is advertised into a control plane instance different
from the one used to establish the LSP because the addresses MAY be
allocated in both domains.
3. Applicability Statement
The method is applicable for both hierarchical LSP [HIERAR] and LSP
stitching [STITCH].
The method is applicable for bundled links.
4. Backward Compatibility Considerations
The method does not impact the method to exchange unnumbered FA
information described in [RFC3477]. This mechanism can be safely
used in combination with the new mechanisms described here and is
functionally equivalent to using the new C-Type indicating an
unnumbered link with target control plane instance identifier with
the Target Control Plane Instance value set to zero.
The method obsoletes the method to exchange the numbered FA
information described in [HIERAR]. This is not believed to be an
issue as an informal survey indicated that dynamically signalled
numbered FAs had not been deployed. Indeed it was the attempt to
implement numbered FAs that gave rise to the work on this document.
Shiomoto Expires April 17, 2006 [Page 11]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
5. Security Considerations
[RFC3477] points out that one can argue that the use of the extra
interface identify that it provides could make an RSVP message harder
to spoof. In that respect, the minor extensions to the protocol made
in this document do not constitute an additional security risk, but
could also be said to improve security.
It should be noted that the ability of an ingress LSR to request that
an egress LSR advertise an LSP as a TE link MUST be subject to
appropriate policy checks at the egress LSR. That is, the egress LSR
MUST NOT automatically accept the word of the ingress unless it is
configured with such a policy.
6. IANA Considerations
This document defines three new C-Types for the
LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are
managed by IANA, and IANA is requested to assign values to the new C-
Types as tabulated in section 2.3 and described in sections 2.3.2,
2.3.3 and 2.3.4.
7. Acknowledgement
The authors would like to thank John Drake for valuable discussiond
and comments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[HIERAR] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08
(work in progress), September 2002.
Shiomoto Expires April 17, 2006 [Page 12]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
[STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path
Stitching with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-01, (work in progress),
July 2005.
8.2. Informative References
[LMP] Lang, J. (Ed.), "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-10, (work in progress), October 2003.
[MRN] Shiomoto, K., et al, " Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)", draft-shiomoto-
ccamp-gmpls-mrn-reqs-02, (work in progress), July 2005.
Author's Addresses
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp
Richard Rabbat
Fujitsu Laboratories of America
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
United States of America
Phone: +1 408-530-4537
Email: richard@us.fujitsu.com
Shiomoto Expires April 17, 2006 [Page 13]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
Arthi Ayyangar
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Phone:
Email: arthi@juniper.net
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
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
Shiomoto Expires April 17, 2006 [Page 14]
draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt October 2005
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.
Shiomoto Expires April 17, 2006 [Page 15]