draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt   draft-ietf-mpls-rsvp-te-no-php-oob-mapping-02.txt 
MPLS Working Group Z. Ali MPLS Working Group Z. Ali
G. Swallow G. Swallow
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
R. Aggarwal R. Aggarwal
Juniper Networks Juniper Networks
Intended status: Standard Track June 19, 2008 Intended status: Standard Track March 05, 2009
Expires: December 2008 Expires: September 04, 2009
Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs
draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt draft-ietf-mpls-rsvp-te-no-php-oob-mapping-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance
any applicable patent or other IPR claims of which he or she is with the provisions of BCP 78 and BCP 79. This document may
aware have been or will be disclosed, and any of which he or she contain material from IETF Documents or IETF Contributions
becomes aware will be disclosed, in accordance with Section 6 of published or made publicly available before November 10,
BCP 79. 2008. The person(s) controlling the copyright in some of
this material may not have granted the IETF Trust the right
to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license
from the person(s) controlling the copyright in such
materials, this document may not be modified outside the
IETF Standards Process, and derivative works of it may not
be created outside the IETF Standards Process, except to
format it for publication as an RFC or to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working
other groups may also distribute working documents as Internet- groups. Note that other groups may also distribute working
Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of
months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by
documents at any time. It is inappropriate to use Internet- other documents at any time. It is inappropriate to use
Drafts as reference material or to cite them other than as "work Internet-Drafts as reference material or to cite them other
in progress." than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt 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 December 19, 2008.
Copyright Notice The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The IETF Trust (2008). This Internet-Draft will expire on September 04, 2009.
Abstract Abstract
There are many deployment scenarios which require Egress LSR to There are many deployment scenarios which require Egress LSR to
receive binding of the RSVP-TE LSP to an application, and payload receive binding of the RSVP-TE LSP to an application, and payload
identification, using some "out-of-band" (OOB) mechanism. This identification, using some "out-of-band" (OOB) mechanism. This
document proposes protocol mechanisms to address this document proposes protocol mechanisms to address this
requirement. The procedures described in this document are requirement. The procedures described in this document are
equally applicable for point-to-point (P2P) and point-to- equally applicable for point-to-point (P2P) and point-to-
multipoint (P2MP) LSPs. multipoint (P2MP) LSPs.
Conventions used in this document Conventions used in this document
skipping to change at page 3, line 15 skipping to change at page 3, line 15
There are other applications that require non-PHP behavior. When There are other applications that require non-PHP behavior. When
RSVP-TE P2MP LSPs are used to carry IP multicast traffic, non-PHP RSVP-TE P2MP LSPs are used to carry IP multicast traffic, non-PHP
behavior enables a leaf LSR to identify the P2MP TE LSP on which behavior enables a leaf LSR to identify the P2MP TE LSP on which
traffic is received. Hence, the egress LSR can determine whether traffic is received. Hence, the egress LSR can determine whether
traffic is received on the expected P2MP LSP and discard traffic traffic is received on the expected P2MP LSP and discard traffic
that is not received on the expected P2MP LSP. Non-PHP behavior that is not received on the expected P2MP LSP. Non-PHP behavior
is also required to determine the context of upstream assigned is also required to determine the context of upstream assigned
labels [UPSTREAM] when the context is a MPLS LSP. labels [UPSTREAM] when the context is a MPLS LSP.
This document defines two new bits in the Attributes Flags TLV of This document defines two new bits in the Attributes Flags TLV of
the LSP_ATTRIBUTES object defined in [RFC4420]: one bit for the LSP_ATTRIBUTES object defined in [RFC5420]: one bit for
communication of non-PHP behavior, and one bit to indicate that communication of non-PHP behavior, and one bit to indicate that
the binding of the LSP to an application and payload identifier the binding of the LSP to an application and payload identifier
(payload-Id) needs to be learned via an out-of-band mapping (payload-Id) needs to be learned via an out-of-band mapping
mechanism. mechanism.
The procedures described in this document are equally applicable The procedures described in this document are equally applicable
for P2P and P2MP LSPs. Specification of the OOB communication for P2P and P2MP LSPs. Specification of the OOB communication
mechanism(s) is beyond the scope of the document. mechanism(s) is beyond the scope of the document.
2. RSVP-TE signaling extensions 2. RSVP-TE signaling extensions
This section describes the signaling extensions required to This section describes the signaling extensions required to
address the above-mentioned requirements. address the above-mentioned requirements.
2.1. Signaling non-PHP behavior 2.1. Signaling non-PHP behavior
In order to request non-PHP behavior for RSVP-TE LSP, this In order to request non-PHP behavior for RSVP-TE LSP, this
document defines a new bit in the Attributes Flags TLV of the document defines a new bit in the Attributes Flags TLV of the
LSP_ATTRIBUTES object defined in [RFC4420]: LSP_ATTRIBUTES object defined in [RFC5420]:
Bit Number 6 (TBD): non-PHP behavior desired bit. Bit Number 6 (TBD): non-PHP behavior desired bit.
This bit SHOULD be set by Ingress node in the Attributes Flags This bit SHOULD be set by Ingress node in the Attributes Flags
TLV of the LSP_ATTRIBUTES object in the Path message for the LSP TLV of the LSP_ATTRIBUTES object in the Path message for the LSP
that desires Non-PHP behavior. This bit MUST NOT be modified by that desires Non-PHP behavior. This bit MUST NOT be modified by
any other nodes in the network. Nodes other than the Egress nodes any other nodes in the network. Nodes other than the Egress nodes
SHOULD ignore this bit. SHOULD ignore this bit.
If an egress node receiving the Path message, supports the If an egress node receiving the Path message, supports the
skipping to change at page 4, line 15 skipping to change at page 4, line 15
An ingress node requesting non-PHP behavior MAY examine the label An ingress node requesting non-PHP behavior MAY examine the label
value corresponding to the Egress node(s) in the RRO, and MAY value corresponding to the Egress node(s) in the RRO, and MAY
send a Path Tear to the Egress which assigns a Null label value. send a Path Tear to the Egress which assigns a Null label value.
2.2. Signaling OOB Mapping Indication 2.2. Signaling OOB Mapping Indication
In order to indicate to the Egress LSR that binding of RSVP-TE In order to indicate to the Egress LSR that binding of RSVP-TE
LSP to an application and payload identification is being LSP to an application and payload identification is being
communicated by an OOB mechanism, this document defines a new bit communicated by an OOB mechanism, this document defines a new bit
in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined
in [RFC4420]: in [RFC5420]:
Bit Number 7 (TBD): OOB mapping indication bit. Bit Number 7 (TBD): OOB mapping indication bit.
This bit SHOULD be set by Ingress node in the Attributes Flags This bit SHOULD be set by Ingress node in the Attributes Flags
TLV of the LSP_ATTRIBUTES object in the Path message for the LSP TLV of the LSP_ATTRIBUTES object in the Path message for the LSP
that desires OOB mapping. This bit MUST NOT be modified by any that desires OOB mapping. This bit MUST NOT be modified by any
other nodes in the network. Nodes other than the Egress nodes other nodes in the network. Nodes other than the Egress nodes
SHOULD ignore this bit. SHOULD ignore this bit.
If an egress node receiving the Path message, supports the If an egress node receiving the Path message, supports the
skipping to change at page 5, line 22 skipping to change at page 5, line 22
notify requests were included when the LSPs were initially setup, notify requests were included when the LSPs were initially setup,
Notify message (as defined in [RFC3473]) MAY also be used for Notify message (as defined in [RFC3473]) MAY also be used for
delivery of this information to the Ingress node. Egress node may delivery of this information to the Ingress node. Egress node may
implement a cleanup timer for this purpose. The time-out value is implement a cleanup timer for this purpose. The time-out value is
a local decision at the Egress, with recommended default value is a local decision at the Egress, with recommended default value is
to be added later. to be added later.
3. Security Considerations 3. Security Considerations
This document does not introduce any new security issues above This document does not introduce any new security issues above
those identified in [RFC3209], [RFC4420] and [RSVP-TE-P2MP]. those identified in [RFC3209], [RFC5420] and [RSVP-TE-P2MP].
4. IANA Considerations 4. IANA Considerations
4.1. Attribute Flags for LSP_ATTRIBUTES object 4.1. Attribute Flags for LSP_ATTRIBUTES object
The following new bit is being defined for the Attributes Flags The following new bit is being defined for the Attributes Flags
TLV in the LSP_ATTRIBUTES object. The numeric value is to be TLV in the LSP_ATTRIBUTES object. The numeric value is to be
assigned by IANA. assigned by IANA.
o Non-PHP behavior desired bit - Bit Number 6 (Suggested value). o Non-PHP behavior desired bit - Bit Number 6 (Suggested value).
skipping to change at page 6, line 14 skipping to change at page 6, line 14
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Yakov Rekhter for his suggestions The authors would like to thank Yakov Rekhter for his suggestions
on the draft. on the draft.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC4420] A. Farrel, D. Papadimitriou, J. P. Vasseur and A. [RFC5420] A. Farrel, D. Papadimitriou, J. P. Vasseur and A.
Ayyangar, "Encoding of Attributes for Multiprotocol Ayyangar, "Encoding of Attributes for Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP) Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", RFC 4420, February 2006. Establishment Using RSVP-TE", RFC 5420.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al, [RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al,
"Extensions to RSVP-TE for Point-to-Multipoint TE "Extensions to RSVP-TE for Point-to-Multipoint TE
LSPs", RFC4875. LSPs", RFC4875.
[RFC3473] L. Berger, Editor, "Generalized Multi-Protocol Label [RFC3473] L. Berger, Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
6.2. Informative References 6.2. Informative References
[MVPN] E. Rosen, R. Aggarwal et al, "Multicast in MPLS/BGP IP [MVPN] E. Rosen, R. Aggarwal et al, "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-06.txt. VPNs", draft-ietf-l3vpn-2547bis-mcast-07.txt.
[VPLS] R. Aggarwal, et al, "Propagation of VPLS IP Multicast [VPLS] R. Aggarwal, et al, "Propagation of VPLS IP Multicast
Group Membership Information", draft-raggarwa-l2vpn- Group Membership Information", draft-raggarwa-l2vpn-
vpls-mcast-ctrl-00.txt, work in progress. vpls-mcast-ctrl-00.txt, work in progress.
[UPSTREAM] TBA. [UPSTREAM] TBA.
Author's Addresses Author's Addresses
Zafar Ali Zafar Ali
skipping to change at page 7, line 19 skipping to change at page 7, line 19
Email: zali@cisco.com Email: zali@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
Email: swallow@cisco.com Email: swallow@cisco.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
Email: rahul@juniper.net Email: rahul@juniper.net
Intellectual Property Statement Copyright Notice
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 Copyright (c) 2009 IETF Trust and the persons identified as
assurances of licenses to be made available, or the result of an the document authors. All rights reserved.
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 This document is subject to BCP 78 and the IETF Trust's
any copyrights, patents or patent applications, or other Legal Provisions Relating to IETF Documents in effect on the
proprietary rights that may cover technology that may be required date of publication of this document
to implement this standard. Please address the information to (http://trustee.ietf.org/license-info). Please review these
the IETF at ietf-ipr@ietf.org. documents carefully, as they describe your rights and
restrictions with respect to this document.
Disclaimer of Validity Legal
This document and the information contained herein are provided This documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FITNESS FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
 End of changes. 22 change blocks. 
55 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/