idnits 2.17.1 draft-ietf-pim-join-attributes-for-lisp-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2014) is 3703 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'AFI' is defined on line 270, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arango 3 Internet-Draft S. Venaas 4 Intended status: Experimental I. Kouvelas 5 Expires: September 7, 2014 Cisco Systems 6 March 6, 2014 8 PIM Join Attributes for LISP Environments 9 draft-ietf-pim-join-attributes-for-lisp-00.txt 11 Abstract 13 This document defines two PIM Join/Prune attributes that support the 14 construction of multicast distribution trees where the root and 15 receivers are located in different LISP sites. These attributes 16 allow the receiver site to select between unicast and multicast 17 transport and to convey the receiver RLOC address to the control 18 plane of the root xTR. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 7, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 56 3. PIM Join/Prune Attributes . . . . . . . . . . . . . . . . . . 3 57 4. The Transport Attribute . . . . . . . . . . . . . . . . . . . 3 58 4.1. Transport Attribute Format . . . . . . . . . . . . . . . 4 59 4.2. Using the Transport Attribute . . . . . . . . . . . . . . 4 60 5. Receiver RLOC Attribute . . . . . . . . . . . . . . . . . . . 4 61 5.1. Receiver RLOC Attribute Format . . . . . . . . . . . . . 5 62 5.2. Using the Receiver RLOC Attribute . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The construction of multicast distribution trees where the root and 71 receivers are located in different LISP sites [RFC6830] is defined in 72 [RFC6831]. Creation of (root-EID,G) state in the root site requires 73 that unicast LISP-encapsulated Join/Prune messages be sent from an 74 xTR on the receiver site to an xTR on the root site. 76 [RFC6831] specifies that (root-EID,G) data packets are to be LISP- 77 encapsulated into (root-RLOC,G) multicast packets. However, a wide 78 deployment of multicast connectivity between LISP sites is unlikely 79 to happen any time soon. In fact, some implementations are initially 80 focusing on unicast transport with head-end replication between root 81 and receiver sites. 83 The unicast LISP-encapsulated Join/Prune message specifies the (root- 84 EID,G) state that needs to be established in the root site, but 85 conveys nothing about the receivers capability or desire to use 86 multicast as the underlying transport. This document specifies a 87 Join/Prune attribute that allows the receiver to select the desired 88 transport. 90 Knowledge of the receiver RLOC is also essential to the control plane 91 of the root xTR. It determines the downstream destination for 92 unicast head-end replication and identifies the receiver xTR that 93 needs to be notified should the root of the distribution tree move to 94 another site. 96 The outer source address field of the encapsulated Join/Prune message 97 contains an RLOC address of the receiver xTR. This source address is 98 message to the root xTR RLOC destination. Due to policy and load 99 balancing considerations, the selected source address may not be the 100 RLOC on which the receiver site wishes to receive a particular flow. 101 This document specifies a Join/Prune attribute that conveys the 102 appropriate receiver RLOC address to the control plane of the root 103 xTR. 105 2. Requirements Notation 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. PIM Join/Prune Attributes 113 PIM Join/Prune attributes are defined in [RFC5384] by introducing a 114 new Encoded-Source type that, in addition to the Join/Prune source, 115 can carry multiple type-length-value (TLV) attributes. These 116 attributes apply to the individual Join/Prune sources on which they 117 are stored. 119 The attributes defined in this document conform to the format of the 120 encoding type defined in [RFC5384]. The attributes would typically 121 be the same for all the sources in the Join/Prune message. Hence we 122 RECOMMEND using the hierarchical Join/Prune attribute scheme defined 123 in [I-D.venaas-pim-hierarchicaljoinattr]. This hirarchichal system 124 allows attributes to be conveyed on the Upstream Neighbor Address 125 field, thus enabling the efficient application of a single attribute 126 instance to all the sources in the Join/Prune message. 128 LISP xTRs do not exchange PIM Hello Messages and hence no Hello 129 option is defined to negotiate support for these attributes. Systems 130 that support unicast head-end replication are assumed to support 131 these attributes. 133 4. The Transport Attribute 135 It is essential that a mechanism be provided by which the desired 136 transport can be conveyed by receiver sites. Root sites with 137 multicast connectivity will want to leverage multicast replication. 138 However, not all receiver sites can be expected to have multicast 139 connectivity. It is thus desirable that root sites be prepared to 140 support (root-EID,G) state with a mixture of multicast and unicast 141 output state. This document specifies a Join/Prune attribute that 142 allows the receiver to select the desired underlying transport. 144 4.1. Transport Attribute Format 146 0 1 2 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 |F|E| Type = 5 | Length = 1 | Transport | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 F-bit: The Transitive bit. Specifies whether the attribute is 153 transitive or non-transitive. MUST be set to zero. This 154 attribute is ALWAYS non-transitive. 156 E-bit: End-of-Attributes bit. Specifies whether this attribute is 157 the last. Set to zero if there are more attributes. Set to 1 if 158 this is the last attribute. 160 Type: The Transport Attribute type is 5. 162 Length: The length of the Transport Attribute value. MUST be set 163 to 1. 165 Transport: The type of transport being requested. Set to 0 for 166 multicast. Set to 1 for unicast. 168 4.2. Using the Transport Attribute 170 Hierarchical Join/Prune attribute instances 171 [I-D.venaas-pim-hierarchicaljoinattr] SHOULD be used when the same 172 Transport Attribute is to be applied to all the sources within the 173 Join/Prune message or all the sources within a group set. The root 174 xTR MUST accept Transport Attributes in the Upstream Neighbor 175 Encoded-Unicast address, Encoded-Group addresses, and Encoded-Source 176 addresses. 178 There MUST NOT be more than one Transport Attribute within the same 179 encoded address. If an encoded address has more than one instance of 180 the attribute, the root xTR MUST discard all affected Join/Prune 181 sources. 183 5. Receiver RLOC Attribute 185 The root xTR must know the receiver RLOC addresses of all receiver 186 sites for a given (root-EID,G) so that it can perform unicast LISP- 187 encapsulation of multicast data packets to each and every receiver 188 site that has requested unicast head-end replication. 190 To support mobility of EIDs, the root xTR must keep track of ALL 191 receiver RLOCs even when the corresponding downstream site has not 192 requested unicast replication. The root xTR may detect that a local 193 multicast source "root-EID" has moved to a remote LISP site. Under 194 such circumstances LISP sends a SMR message to all receiver xTRs, 195 prompting them to update their map cache. This is only possible if 196 LISP can obtain from PIM the set of all receiver RLOCS that have 197 active Join state for the root-EID. 199 The outer source address field of the encapsulated Join/Prune message 200 contains an RLOC address of the receiver xTR. LISP xTRs, as edge 201 devices, are commonly subject to URPF checks by the network providers 202 on each core-facing interface. The source address for the 203 encapsulation header must therefore be the RLOC of the core-facing 204 interface used to physically transmit the encapsulated Join/Prune 205 message. Due to policy and load balancing considerations, that may 206 not be the RLOC on which the receiver site wishes to receive a 207 particular flow. This document specifies a Join/Prune attribute that 208 conveys the appropriate receiver RLOC address to the control plane of 209 the root xTR. 211 5.1. Receiver RLOC Attribute Format 213 0 1 2 3 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |F|E| Type = 6 | Length | Addr Family | Receiver RLOC 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 219 F-bit: The Transitive bit. Specifies whether this attribute is 220 transitive or non-transitive. MUST be set to zero. This 221 attribute is ALWAYS non-transitive. 223 E-bit: End-of-Attributes bit. Specifies whether this attribute is 224 the last. Set to zero if there are more attributes. Set to 1 if 225 this is the last attribute. 227 Type: The Receiver RLOC Attribute type is 6. 229 Length: The length in octets of the attribute value. MUST be set 230 to the length in octets of the receiver RLOC address plus one 231 octet to account for the Address Family field. 233 Addr Family: The PIM Address Family of the receiver RLOC as defined 234 in [RFC4601]. 236 Receiver RLOC: The RLOC address on which the receiver xTR wishes to 237 receiver the unicast-encapsulated flow."> 239 5.2. Using the Receiver RLOC Attribute 241 Hierarchical Join/Prune attribute instances 242 [I-D.venaas-pim-hierarchicaljoinattr] SHOULD be used when the same 243 Receiver RLOC attribute is to be applied to all the sources within 244 the message or all the sources within a group set. The root xTR MUST 245 accept Transport Attributes in the Upstream Neighbor Encoded-Unicast 246 address, Encoded-Group addresses, and Encoded-Source addresses. 248 There MUST NOT be more than one Receiver RLOC Attribute within the 249 same encoded address. If an encoded address has more than one 250 instance of the attribute, the root xTR MUST discard all affected 251 Join/Prune sources. 253 6. Security Considerations 255 Security of the Join Attribute is only guaranteed by the security of 256 the PIM packet. The attributes specified herein do not enhance or 257 diminish the privacy or authenticity of a Join/Prune message. A site 258 that legitimately or maliciously sends and delivers a Join/Prune 259 message to another site will equally be able to append these and any 260 other attributes it wishes. 262 7. IANA Considerations 264 Two new PIM Join/Prune attribute types need to be assigned. Type 5 265 is being requested for the Transport Attribute. Type 6 is being 266 requested for the Receiver RLOC Attribute. 268 8. Normative References 270 [AFI] IANA, , "Address Family Numbers", 271 http://www.iana.org/assignments/address-family-numbers, . 273 [I-D.venaas-pim-hierarchicaljoinattr] 274 Venaas, S., Kouvelas, I., and J. Arango, "Hierarchical 275 Join/Prune Attributes", draft-venaas-pim- 276 hierarchicaljoinattr-00 (work in progress), February 2013. 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 282 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 283 Protocol Specification (Revised)", RFC 4601, August 2006. 285 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 286 Independent Multicast (PIM) Join Attribute Format", RFC 287 5384, November 2008. 289 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 290 Locator/ID Separation Protocol (LISP)", RFC 6830, January 291 2013. 293 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 294 Locator/ID Separation Protocol (LISP) for Multicast 295 Environments", RFC 6831, January 2013. 297 Authors' Addresses 299 Jesus Arango 300 Cisco Systems 301 170 Tasman Drive 302 San Jose, CA 95134 303 USA 305 Email: jearango@cisco.com 307 Stig Venaas 308 Cisco Systems 309 170 Tasman Drive 310 San Jose, CA 95134 311 USA 313 Email: stig@cisco.com 315 Isidor Kouvelas 316 Cisco Systems 317 170 Tasman Drive 318 San Jose, CA 95134 319 USA 321 Email: kouvelas@cisco.com