CCAMP Working Group Zafar Ali Internet Draft Cisco Systems, Inc. Intended status: Informational October 26, 2009 Expires: April 25,2009 Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs draft-ali-mpls-sig-pid-multiplexing-case-02.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 September 08, 2009. Expires September 2009 [Page 1] draft-ali-mpls-sig-pid-multiplexing-case-02.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 September 2009 [Page 2] draft-ali-mpls-sig-pid-multiplexing-case-02.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 September 2009 [Page 3] draft-ali-mpls-sig-pid-multiplexing-case-02.txt This document has no IANA actions. Expires September 2009 [Page 4] draft-ali-mpls-sig-pid-multiplexing-case-02.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 Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Expires September 2009 [Page 5] draft-ali-mpls-sig-pid-multiplexing-case-02.txt Legal This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires September 2009 [Page 6]