idnits 2.17.1 draft-kini-pwe3-inband-cc-offset-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 14, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ID.VCCV-MF' is defined on line 157, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-delregno-pwe3-vccv-mandatory-features-01 == Outdated reference: A later version (-02) exists of draft-kini-pwe3-pkt-encap-efficient-ip-mpls-01 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-fat-pw-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group S. Kini 3 Internet-Draft D. Sinicrope 4 Intended Status: Standards Track Ericsson 5 Expires: September 2011 March 14, 2011 7 Pseudowire Virtual Circuit Connectivity Verification (VCCV): 8 An Inband Control Channel using offset 9 draft-kini-pwe3-inband-cc-offset-01.txt 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and 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 months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 15, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 Pseudowires need an inband control channel (CC) to do VCCV such that 51 OAM and data packets follow the same path. PWs without a Control Word 52 (CW) do not have an inband CC as defined in RFC5085. This document 53 defines a simple extension to the TTL expiry CC (Type 3) to do inband 54 VCCV. This can be used even without a CW. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions used in this document . . . . . . . . . . . . . . . 4 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 Appendix A: Examples . . . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 OAM functions such as connectivity verification (CV) need an inband 75 channel to do their operations. Only an inband control channel 76 ensures that packets carrying OAM messages follow the same path as 77 the data packets that they are doing OAM operations for. Most PW 78 deployments today do not have CW enabled. However the control 79 channels defined in [VCCV] provide an inband CC only when CW is 80 enabled. Moreover enabling CW prevents from looking beyond the label 81 stack to do multipath decisions. At an intermediate LSR, looking at 82 an IP header beyond the label stack to do multipath is desirable 83 since it is a commonly available capability in current 84 implementations and also helps to do multipath load sharing based on 85 a true end to end flow (e.g. [ID.PPW-EIM]), rather than rely on 86 additional mechanisms such as [FAT-PW]. This document briefly 87 describes the problem with the TTL Expiry CC (Type 3) in section 3. 88 A simple extension to this CC to solve this problem is described in 89 section 4. 91 2. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Problem Statement 99 A VCCV control channel (CC) that uses TTL expiry is not inband when 100 the intermediate nodes along a LSP look beyond the label stack to do 101 multipath forwarding decisions. However it is mandatory ([ID.VCCV- 102 MF]) and is widely used especially in the commonly deployed scenario 103 of PWs that do not use a CW (Control Word). A PW that uses CW is also 104 unable to take advantage of the presences of multipath in the server 105 layer. Multipath is considered useful for both redundancy as well as 106 load sharing. 108 4. Solution 110 This document defines a new VCCV CC. It is an extension of the TTL 111 Expiry VCCV (Type 3) defined in [VCCV]. In this CC the associated 112 channel starts at a fixed offset after the PW label. This CC is 113 henceforth referred to as Inband-offset VCCV (Type TBA). A fixed 114 number of bytes between the PW label and the start of the associated 115 channel can be used to emulate flow header information and are 116 henceforth referred to as a "pseudo flow header". A VCCV message with 117 a pseudo flow header will follow the same path as that taken by a 118 data packet of the flow, as long as any multipath forwarding decision 119 taken by the intermediate LSRs do not look beyond the pseudo flow 120 header. A pseudo flow header length of 64 bytes is expected to meet 121 the requirements of all current implementations and also meet the 122 requirements of deployments (both current and in the foreseeable 123 future). If a size other than 64 is needed then it can be configured 124 or signaled as an attribute of the PW. The content of the pseudo flow 125 header is set according to the flow that needs an OAM function such 126 as connectivity verification (CV). E.g. if the encapsulation consists 127 of an IP packet following the PW label, then the pseudo flow header 128 would be the IP header of a flow. 130 5. Security Considerations 132 This document does not introduce any new security considerations 133 beyond those already listed in [VCCV]. 135 6. IANA Considerations 137 IANA needs to allocate a value for Inband-offset VCCV in the registry 138 "MPLS VCCV Control Channel Type". Recommend next available bitfield 139 0x8. 141 7. Future work 143 1. Define signaling extensions to convey the size of the offset. 144 2. Authenticate VCCV messages. 146 8. References 148 8.1. Normative References 150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", BCP 14, RFC 2119, March 1997. 153 [VCCV] Nadeau, T., et al, "Pseudowire Virtual Circuit 154 Connectivity Verification (VCCV): A Control Channel for 155 Pseudowires", RFC 5085, December 2007. 157 [ID.VCCV-MF] Del Regno, N., et al, "Mandatory Features of Virtual 158 Circuit Connectivity Verification Implementations", draft- 159 delregno-pwe3-vccv-mandatory-features-01 (work in 160 progress), April 2010. 162 [ID.PPW-EIM] Kini, S., et al, "Encapsulation Methods for Transport 163 of packets over an MPLS PSN - efficient for IP/MPLS", 164 draft-kini-pwe3-pkt-encap-efficient-ip-mpls-01 (work in 165 progress), March 2011. 167 8.2. Informative References 169 [FAT-PW] Bryant, S., et al, "Flow Aware Transport of Pseudowires 170 over an MPLS PSN", draft-ietf-pwe3-fat-pw-04 (work in 171 progress), July 2010. 173 9. Acknowledgements 175 The authors would like to thank Joel Halpern, Luca Martini and 176 Raymond Key for their comments. 178 Appendix A: Examples 180 Consider a PPW-EIM that is setup and an OAM CV has to be done for a 181 specific flow. Say the flow is between IPv4 endpoints with addresses 182 209.85.153.104 and 209.191.122.70 that have a TCP session between 183 ports 80 and 53950 respectively. To perform OAM operations for this 184 flow e.g. to do a VCCV ping for this flow, the encoding of the VCCV 185 packet is as follows. 187 +------------------------------------------------+ 188 |PSN Tunnel & PSN Physical Headers | m octets 189 |------------------------------------------------| 190 |PW Label (S=0 if FAT-PW label present, else S=1)| 4 191 |------------------------------------------------| 192 |Optional FAT-PW label S=1 | 4 193 |------------------------------------------------| 194 |Ver Hdr-len TOS Total Len | Start pseudo 195 |------------------------------------------------| flow hdr 196 | Identification Flags Frag Offset | 197 |------------------------------------------------| 198 |TTL Protocol Header Checksum | 199 |------------------------------------------------| 200 | Source IP Addr 209.85.153.104 | 201 |------------------------------------------------| 202 | Destination IP Addr 209.191.122.70 | 203 |------------------------------------------------| 204 | Source Port (80) Destination Port (53950) | 64 byte 205 |------------------------------------------------| pseudo flow hdr 206 . . 207 . . 208 . (Pad bytes) . 209 . . 210 . . 211 . . 212 | | End pseudo 213 +------------------------------------------------+ flow hdr 214 | | 215 . VCCV ping packet . 216 . . 217 | | 218 +------------------------------------------------+ 220 Figure 1 IPv4/v6 packet encapsulated into PPW without CW 222 Authors' Addresses 224 Sriganesh Kini 225 Ericsson 226 300 Holger Way, San Jose, CA 95134 227 EMail: sriganesh.kini@ericsson.com 229 David Sinicrope 230 Ericsson 231 8001 Development Dr, Research Triangle Park, NC 27709 232 EMail: david.sinicrope@ericsson.com