idnits 2.17.1 draft-ali-mpls-sig-pid-multiplexing-case-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 192. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3471], [RFC3473], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Zafar Ali 3 Internet Draft Cisco Systems, Inc. 4 Intended status: Informational July 07 2008 5 Expires: January 06 2009 7 Signaled PID When Multiplexing Multiple Payloads over RSVP-TE LSPs 8 draft-ali-mpls-sig-pid-multiplexing-case-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 6, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 There are many deployment scenarios where an RSVP-TE LSP carries 44 multiple payloads. In these cases, it gets ambiguous on what 45 should value should be carried as L3PID in the Label Request 46 Object [RFC3209] or G-PID in the Generalized Label Request Object 48 [RFC3471], [RFC3473]. The document propose use of some dedicated 49 PID values to cover some typical cases of multiple payload 50 carried by the LSP, including that indicates to the egress node 51 to ignore signaling to learn payload carried by the LSP. 53 Table of Contents 55 1. Introduction...............................................2 56 2. Some use cases.............................................3 57 2.1. PID = 0x0800 (IPv4 Payload)...........................3 58 2.2. PID = 0x86DD (IPv6 Payload)...........................3 59 2.3. IPv4+IPv6 PID.........................................3 60 2.4. Unknown PID...........................................3 61 3. Security Considerations....................................4 62 4. IANA Considerations........................................4 63 5. References.................................................4 64 5.1. Normative References..................................4 65 5.2. Informative References................................4 66 Author's Addresses............................................4 67 Intellectual Property Statement...............................4 68 Disclaimer of Validity........................................5 70 1. Introduction 72 When an RSVP-TE LSP is used to carry multiple payload type (e.g., 73 IPv6 and IPv4 payloads on the same LSP), it gets ambiguous on 74 what value should be carried as L3PID in the Label Request Object 75 [RFC3209] or G-PID in the Generalized Label Request Object 76 [RFC3471], [RFC3473]. It also gets unclear at the receiver that 77 source may be multiplexing multiple payloads on the same RSVP-TE 78 LSP. The document clarifies some of the use cases where RSVP-TE 79 LSP is used to carry multiple payloads and what PID should be 80 used during signaling. It also suggests use of an "unknown" PID 81 in signaling when PID is completely determined by scope outside 82 of signaling. 84 At this stage document is written without use of formal language, 85 but the idea is to first see if the WG feedback on the need for 86 this work. 88 2. Some use cases 90 This section outlines some used cases. 92 2.1. PID = 0x0800 (IPv4 Payload) 94 This case is optimized for carrying IPv4 payload such that IPv4 95 packets travel without need for any additional information 96 (label) to identify the payload, i.e., IPv4 payload is identified 97 by the signaling. If multiplexing of additional payloads is 98 desired, some in-band data plane mechanisms are needed to 99 identify the payload. E.g., if IPv4 and IPv6 payloads are 100 multiplexed on the same tunnel, an IPv6 Explicit Null Label or 101 some other application label is used to identify IPv6 payload. 103 2.2. PID = 0x86DD (IPv6 Payload) 105 This case is optimized for carrying IPv6 payload such that IPv6 106 packets travel without need for any additional information 107 (label) to identify the payload, i.e., IPv6 payload is identified 108 by the signaling. If multiplexing of additional payloads is 109 desired, some in-band data plane mechanisms are needed to 110 identify the payload. E.g., if IPv4 and IPv6 payloads are 111 multiplexed on the same tunnel, an IPv4 Explicit Null Label or 112 some other application label is used to identify IPv4 payload. 114 2.3. IPv4+IPv6 PID 116 This case is optimized for multiplexing IPv4 and IPv6 payloads 117 such that both IPv6 and IPv6 packets travel without need for any 118 additional information (label) to identify the payload. In this 119 case the Egress node looks at the IP version field to identify 120 the payload type (while demultiplexing the traffic). If 121 multiplexing of additional payloads or application is desired, 122 some in-band data plane mechanisms are needed to identify the 123 payload. 125 L3PID and G-PID code point for this are TBA. 127 2.4. Unknown PID 129 This case is the case where payload to be carried by the LSP is 130 not known to the Ingress node. Payload identification is obtained 131 via some means other than signaling and egress node ignores the 132 signaled PID. 134 Unknown PID with code point of 0x00 is already defined for G-PID 135 in the Generalized Label Request Object [RFC3471], [RFC3473]. 136 L3PID code point for this is TBA. 138 3. Security Considerations 140 TBA 142 4. IANA Considerations 144 TBA 146 5. References 148 5.1. Normative References 150 [RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V., 151 Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 152 3209, December 2001. 154 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 155 Switching (GMPLS) Signaling Functional Description", RFC 3471, 156 January 2003. 158 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 159 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 160 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 162 5.2. Informative References 164 Author's Addresses 166 Zafar Ali 167 Cisco Systems, Inc. 168 Email: zali@cisco.com 170 Intellectual Property Statement 172 The IETF takes no position regarding the validity or scope of any 173 Intellectual Property Rights or other rights that might be 174 claimed to pertain to the implementation or use of the technology 175 described in this document or the extent to which any license 176 under such rights might or might not be available; nor does it 177 represent that it has made any independent effort to identify any 178 such rights. Information on the procedures with respect to 179 rights in RFC documents can be found in BCP 78 and BCP 79. 181 Copies of IPR disclosures made to the IETF Secretariat and any 182 assurances of licenses to be made available, or the result of an 183 attempt made to obtain a general license or permission for the 184 use of such proprietary rights by implementers or users of this 185 specification can be obtained from the IETF on-line IPR 186 repository at http://www.ietf.org/ipr. 188 The IETF invites any interested party to bring to its attention 189 any copyrights, patents or patent applications, or other 190 proprietary rights that may cover technology that may be required 191 to implement this standard. Please address the information to 192 the IETF at ietf-ipr@ietf.org. 194 Disclaimer of Validity 196 This document and the information contained herein are provided 197 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 198 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 199 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 200 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 201 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 202 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 203 FITNESS FOR A PARTICULAR PURPOSE. 205 Copyright Statement 207 Copyright (C) The IETF Trust (2008). 209 This document is subject to the rights, licenses and restrictions 210 contained in BCP 78, and except as set forth therein, the authors 211 retain all their rights.