MPLS Working Group Zafar Ali
Internet Draft Cisco Systems, Inc.
Intended status: Informational October 25, 2010
Expires: April 25, 2011
Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs
draft-ali-mpls-sig-pid-multiplexing-case-04.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 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
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 25, 2011.
Expires April 2011 [Page 1]
draft-ali-mpls-sig-pid-multiplexing-case-04.txt
Abstract
There are many deployment scenarios where an RSVP-TE LSP carries
multiple payloads. In these cases, it gets ambiguous on what
should value should be carried as L3PID in the Label Request
Object [RFC3209] or G-PID in the Generalized Label Request Object
[RFC3471], [RFC3473]. The document proposes use of some dedicated
PID values to cover some typical cases of multiple payloads
carried by the 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. Some use cases.............................................3
2.1. PID = 0x0800 (IPv4 Payload)...........................3
2.2. PID = 0x86DD (IPv6 Payload)...........................3
2.3. Ignore PID............................................3
3. Security Considerations....................................3
4. IANA Considerations........................................3
5. References.................................................5
5.1. Normative References..................................5
5.2. Informative References................................5
Author's Addresses............................................5
Copyright Notice..............................................5
Legal.........................................................6
1. Introduction
When an RSVP-TE LSP is used to carry multiple payload type (e.g.,
IPv6 and IPv4 payloads on the same LSP), it gets ambiguous on
what value should be carried as L3PID in the Label Request Object
[RFC3209] or G-PID in the Generalized Label Request Object
[RFC3471], [RFC3473]. It also gets unclear at the receiver that
source may be multiplexing multiple payloads on the same RSVP-TE
LSP. The document clarifies some of the use cases where RSVP-TE
LSP is used to carry multiple payloads and what PID should be
used during signaling.
Expires April 2011 [Page 2]
draft-ali-mpls-sig-pid-multiplexing-case-04.txt
2. Some use cases
This section outlines some used cases.
2.1. PID = 0x0800 (IPv4 Payload)
This case is optimized for carrying IPv4 payload such that IPv4
packets travel without need for any additional information
(label) to identify the payload, i.e., IPv4 payload is identified
by the signaling. If multiplexing of additional payloads is
desired, some in-band data plane mechanisms are needed to
identify the payload. E.g., if IPv4 and IPv6 payloads are
multiplexed on the same tunnel, an IPv6 Explicit Null Label or
some other application label is used to identify IPv6 payload.
2.2. PID = 0x86DD (IPv6 Payload)
This case is optimized for carrying IPv6 payload such that IPv6
packets travel without need for any additional information
(label) to identify the payload, i.e., IPv6 payload is identified
by the signaling. If multiplexing of additional payloads is
desired, some in-band data plane mechanisms are needed to
identify the payload. E.g., if IPv4 and IPv6 payloads are
multiplexed on the same tunnel, an IPv4 Explicit Null Label or
some other application label is used to identify IPv4 payload.
2.3. Ignore PID
This case is the case where payload to be carried by the LSP is
not known to the Ingress node. Payload identification is obtained
via some means other than signaling and egress node ignores the
signaled PID. This case is addressed by [OOB-MAPPING].
3. Security Considerations
This document does not introduce any new security issues above
those identified in [RFC3209], [RFC3471] and [RFC3473].
4. IANA Considerations
Expires April 2011 [Page 3]
draft-ali-mpls-sig-pid-multiplexing-case-04.txt
This document has no IANA actions.
Expires April 2011 [Page 4]
draft-ali-mpls-sig-pid-multiplexing-case-04.txt
5. References
5.1. Normative References
[RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V.,
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[OOB-MAPPING] Z. Ali, G. Swallow and R. Aggarwal, "Non PHP
Behavior and out-of-band mapping for RSVP-TE LSPs",
draft-ietf-mpls-rsvp-te-no-php-oob-mapping-02.txt, work
in progress.
5.2. Informative References
Author's Addresses
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Copyright
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Expires April 2011 [Page 5]