One document matched: draft-ali-mpls-rsvp-te-s2l-name-01.txt
Differences from draft-ali-mpls-rsvp-te-s2l-name-00.txt
MPLS Working Group Z. Ali
R. Sawaya
Internet Draft Cisco Systems, Inc.
Intended status: Standard Track July 2007
Expires: January 2008
S2L Name Identification for Point-to-Multipoint TE LSPs
draft-ali-mpls-rsvp-te-s2l-name-01.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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
One of the management requirements for point-to-multipoint (P2MP)
Label Switched Paths (LSPs) in Multi-Protocol Label Switching
Expires January 2008 [Page 1]
Internet-Draft draft-ali-mpls-rsvp-te-s2l-name-01.txt Feb. 2007
(MPLS) and Generalized MPLS (GMPLS) networks is the ability to
identify source-to-leaf (S2L) sub-lsp by name. This document
provides a minor extension to RSVP-TE for P2MP TE LSPs [RSVP-TE-
P2MP] to signal name for S2L sub-lsp.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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
RFC-2119 0.
Table of Contents
1. Introduction...............................................2
2. S2L Attribute Object.......................................3
2.1. Path Message Processing...............................4
3. Security Considerations....................................4
4. IANA Considerations........................................4
5. References.................................................4
5.1. Normative References..................................4
5.2. Informative References................................5
Author's Addresses............................................5
Intellectual Property Statement...............................5
Disclaimer of Validity........................................6
1. Introduction
Session name attribute of the SESSION_ATTRIBUTE object [RSVP-TE]
is widely used by the Service Providers to identify an LSP in
network, usually for management operations. However, in the case
of P2MP LSP, a Path message can be used to signal one or more S2L
sub-LSPs. Session name attribute cannot be used to identify an
S2L by name in a network. This is a considerable limitation for
network management, as service providers like to use meaningful
names not only at the LSP level, but also at the S2L level.
This document addresses the above-mentioned requirement by adding
an optional object called S2L_ATTRIBUTE object to the sub-LSP
descriptor define in [RSVP-TE-P2MP]. Specifically, it proposes to
use the < <S2L_SUB_LSP>, [<EXPLICIT_ROUTE>], [<S2L_ATTRIBUTE>] >
tuple to represents the S2L sub-LSP being signaled in the Path
message. The document defines "S2L name" as an attribute of
Expires August 9, 2008 [Page 2]
Internet-Draft draft-ali-mpls-rsvp-te-s2l-name-01.txt Feb. 2007
S2L_ATTRIBUTE object. If needed, the S2L_ATTRIBUTE object can be
extended to include other S2L scoped attributes.
2. S2L Attribute Object
The S2L_ATTRIBUTE object can optionally appear in a Path message
as part of sub-LSP descriptor define in [RSVP-TE-P2MP].
Specifically, [RSVP-TE-P2MP] enhances path message to signal one
or more S2L sub-LSPs by including the S2L sub-LSP descriptor list
in the Path. This document extends the definition of S2L sub-LSP
descriptor to optionally include S2L_ATTRIBUTE object as follows,
where the syntax follows the augmented Backus-Naur Form (BNF)
form.
<S2L sub-LSP descriptor> ::= <S2L_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
[ <S2L_ATTRIBUTE> ]
S2L_ATTRIBUTE object has a class number TBA by IANA (of type
11bbbbbb), C-Type of TBD. The format is given below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name Length | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// S2L sub-LSP Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where,
Name Length:
The length of the display string before padding, in bytes.
Expires August 9, 2008 [Page 3]
Internet-Draft draft-ali-mpls-rsvp-te-s2l-name-01.txt Feb. 2007
S2L sub-lsp Name:
A null padded string of characters communicating a meaningful
name associated with the S2L.
Reserved (Res)
This field is reserved. It MUST be set to zero on
transmission and MUST be ignored on receipt.
2.1. Path Message Processing
As specified in [RSVP-TE-P2MP] it is possible to signal S2L sub-
LSPs for a given P2MP LSP in one or more Path messages and a
given Path message can contain one or more S2L sub-LSPs. In
either case, the < [<EXPLICIT_ROUTE>] <S2L_SUB_LSP>
[<S2L_ATTRIBUTE> ]> or the < [<P2MP SECONDARY_EXPLICIT_ROUTE>]
<S2L_SUB_LSP> [ <S2L_ATTRIBUTE> ]> tuple is used to specify an
S2L sub-LSP, where S2L sub-lsp name is specified in the
S2L_ATTRIBUTE object. The session name field of the
SESSION_ATTRIBUTE object can optionally be used to describe name
of the P2MP LSP, as described in [RSVP-TE]. Rest of the handling
of <S2L sub-LSP descriptor> follows the procedure specified in
[RSVP-TE-P2MP].
3. Security Considerations
This document does not introduce any new security issues above
those identified in [RSVP-TE], [RFC3473], [RFC4206] and [RSVP-TE-
P2MP].
4. IANA Considerations
New Class Number and type for S2L_ATTRIBUTE object defined in
this document needs to be assigned.
5. References
5.1. Normative References
[RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al,
"Extensions to RSVP-TE for Point-to-Multipoint TE
LSPs", RFC4875.
Expires August 9, 2008 [Page 4]
Internet-Draft draft-ali-mpls-rsvp-te-s2l-name-01.txt Feb. 2007
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473.
5.2. Informative References
[RFC4206] K. Kompella, Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE" [RFC4206]
Author's Addresses
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Robert Sawaya
Cisco Systems, Inc.
Email: rsawaya@cisco.com
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
Expires August 9, 2008 [Page 5]
Internet-Draft draft-ali-mpls-rsvp-te-s2l-name-01.txt Feb. 2007
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, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Expires August 9, 2008 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 05:51:01 |