PWE3 Working Group S. Kini Internet-Draft D. Sinicrope Intended Status: Standards Track Ericsson Expires: September 2011 March 14, 2011 Pseudowire Virtual Circuit Connectivity Verification (VCCV): An Inband Control Channel using offset draft-kini-pwe3-inband-cc-offset-01.txt Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 15, 2011. Copyright Notice Copyright (c) 2011 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. Kini & Sinicrope Expires September 2011 [Page 1] Internet Draft VCCV - Inband CC using offset March 14, 2011 Abstract Pseudowires need an inband control channel (CC) to do VCCV such that OAM and data packets follow the same path. PWs without a Control Word (CW) do not have an inband CC as defined in RFC5085. This document defines a simple extension to the TTL expiry CC (Type 3) to do inband VCCV. This can be used even without a CW. Kini & Sinicrope Expires September 2011 [Page 2] Internet Draft VCCV - Inband CC using offset March 14, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A: Examples . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Kini & Sinicrope Expires September 2011 [Page 3] Internet Draft VCCV - Inband CC using offset March 14, 2011 1. Introduction OAM functions such as connectivity verification (CV) need an inband channel to do their operations. Only an inband control channel ensures that packets carrying OAM messages follow the same path as the data packets that they are doing OAM operations for. Most PW deployments today do not have CW enabled. However the control channels defined in [VCCV] provide an inband CC only when CW is enabled. Moreover enabling CW prevents from looking beyond the label stack to do multipath decisions. At an intermediate LSR, looking at an IP header beyond the label stack to do multipath is desirable since it is a commonly available capability in current implementations and also helps to do multipath load sharing based on a true end to end flow (e.g. [ID.PPW-EIM]), rather than rely on additional mechanisms such as [FAT-PW]. This document briefly describes the problem with the TTL Expiry CC (Type 3) in section 3. A simple extension to this CC to solve this problem is described in section 4. 2. Conventions used in this document 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 [RFC2119]. 3. Problem Statement A VCCV control channel (CC) that uses TTL expiry is not inband when the intermediate nodes along a LSP look beyond the label stack to do multipath forwarding decisions. However it is mandatory ([ID.VCCV- MF]) and is widely used especially in the commonly deployed scenario of PWs that do not use a CW (Control Word). A PW that uses CW is also unable to take advantage of the presences of multipath in the server layer. Multipath is considered useful for both redundancy as well as load sharing. 4. Solution This document defines a new VCCV CC. It is an extension of the TTL Expiry VCCV (Type 3) defined in [VCCV]. In this CC the associated channel starts at a fixed offset after the PW label. This CC is henceforth referred to as Inband-offset VCCV (Type TBA). A fixed number of bytes between the PW label and the start of the associated channel can be used to emulate flow header information and are henceforth referred to as a "pseudo flow header". A VCCV message with a pseudo flow header will follow the same path as that taken by a data packet of the flow, as long as any multipath forwarding decision taken by the intermediate LSRs do not look beyond the pseudo flow Kini & Sinicrope Expires September 2011 [Page 4] Internet Draft VCCV - Inband CC using offset March 14, 2011 header. A pseudo flow header length of 64 bytes is expected to meet the requirements of all current implementations and also meet the requirements of deployments (both current and in the foreseeable future). If a size other than 64 is needed then it can be configured or signaled as an attribute of the PW. The content of the pseudo flow header is set according to the flow that needs an OAM function such as connectivity verification (CV). E.g. if the encapsulation consists of an IP packet following the PW label, then the pseudo flow header would be the IP header of a flow. 5. Security Considerations This document does not introduce any new security considerations beyond those already listed in [VCCV]. 6. IANA Considerations IANA needs to allocate a value for Inband-offset VCCV in the registry "MPLS VCCV Control Channel Type". Recommend next available bitfield 0x8. 7. Future work 1. Define signaling extensions to convey the size of the offset. 2. Authenticate VCCV messages. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [VCCV] Nadeau, T., et al, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [ID.VCCV-MF] Del Regno, N., et al, "Mandatory Features of Virtual Circuit Connectivity Verification Implementations", draft- delregno-pwe3-vccv-mandatory-features-01 (work in progress), April 2010. [ID.PPW-EIM] Kini, S., et al, "Encapsulation Methods for Transport of packets over an MPLS PSN - efficient for IP/MPLS", draft-kini-pwe3-pkt-encap-efficient-ip-mpls-01 (work in progress), March 2011. Kini & Sinicrope Expires September 2011 [Page 5] Internet Draft VCCV - Inband CC using offset March 14, 2011 8.2. Informative References [FAT-PW] Bryant, S., et al, "Flow Aware Transport of Pseudowires over an MPLS PSN", draft-ietf-pwe3-fat-pw-04 (work in progress), July 2010. 9. Acknowledgements The authors would like to thank Joel Halpern, Luca Martini and Raymond Key for their comments. Kini & Sinicrope Expires September 2011 [Page 6] Internet Draft VCCV - Inband CC using offset March 14, 2011 Appendix A: Examples Consider a PPW-EIM that is setup and an OAM CV has to be done for a specific flow. Say the flow is between IPv4 endpoints with addresses 209.85.153.104 and 209.191.122.70 that have a TCP session between ports 80 and 53950 respectively. To perform OAM operations for this flow e.g. to do a VCCV ping for this flow, the encoding of the VCCV packet is as follows. +------------------------------------------------+ |PSN Tunnel & PSN Physical Headers | m octets |------------------------------------------------| |PW Label (S=0 if FAT-PW label present, else S=1)| 4 |------------------------------------------------| |Optional FAT-PW label S=1 | 4 |------------------------------------------------| |Ver Hdr-len TOS Total Len | Start pseudo |------------------------------------------------| flow hdr | Identification Flags Frag Offset | |------------------------------------------------| |TTL Protocol Header Checksum | |------------------------------------------------| | Source IP Addr 209.85.153.104 | |------------------------------------------------| | Destination IP Addr 209.191.122.70 | |------------------------------------------------| | Source Port (80) Destination Port (53950) | 64 byte |------------------------------------------------| pseudo flow hdr . . . . . (Pad bytes) . . . . . . . | | End pseudo +------------------------------------------------+ flow hdr | | . VCCV ping packet . . . | | +------------------------------------------------+ Figure 1 IPv4/v6 packet encapsulated into PPW without CW Kini & Sinicrope Expires September 2011 [Page 7] Internet Draft VCCV - Inband CC using offset March 14, 2011 Authors' Addresses Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 EMail: sriganesh.kini@ericsson.com David Sinicrope Ericsson 8001 Development Dr, Research Triangle Park, NC 27709 EMail: david.sinicrope@ericsson.com Kini & Sinicrope Expires September 2011 [Page 8]