idnits 2.17.1 draft-ietf-mpls-mldp-in-band-signaling-08.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 (November 29, 2012) is 4138 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) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands, Ed. 3 Internet-Draft T. Eckert 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: June 2, 2013 N. Leymann 6 Deutsche Telekom 7 M. Napierala 8 AT&T Labs 9 November 29, 2012 11 Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- 12 to-Multipoint Label Switched Paths 13 draft-ietf-mpls-mldp-in-band-signaling-08 15 Abstract 17 Consider an IP multicast tree, constructed by Protocol Independent 18 Multicast (PIM), needs to pass through an MPLS domain in which 19 Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- 20 Multipoint Labels Switched Paths (LSPs) can be created. The part of 21 the IP multicast tree that traverses the MPLS domain can be 22 instantiated as a multipoint LSP. When a PIM Join message is 23 received at the border of the MPLS domain, information from that 24 message is encoded into mLDP messages. When the mLDP messages reach 25 the border of the next IP domain, the encoded information is used to 26 generate PIM messages that can be sent through the IP domain. The 27 result is an IP multicast tree consisting of a set of IP multicast 28 sub-trees that are spliced together with a multipoint LSP. This 29 document describes procedures how IP multicast trees are spliced 30 together with multipoint LSPs. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 2, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions used in this document . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4 70 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6 71 2.2. Transiting IP multicast source trees . . . . . . . . . . . 6 72 2.3. Transiting IP multicast bidirectional trees . . . . . . . 7 73 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7 75 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8 76 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9 77 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 The mLDP (Multipoint LDP) [RFC6388] specification describes 90 mechanisms for creating point-to-multipoint (P2MP) and multipoint-to- 91 multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are 92 typically used for transporting end-user multicast packets. However, 93 the mLDP specification does not provide any rules for associating 94 particular end-user multicast packets with any particular LSP. Other 95 documents, like [RFC6513], describe applications in which out-of-band 96 signaling protocols, such as PIM and BGP, are used to establish the 97 mapping between an LSP and the multicast packets that need to be 98 forwarded over the LSP. 100 This document describes an application in which the information 101 needed to establish the mapping between an LSP and the set of 102 multicast packets to be forwarded over it is carried in the "opaque 103 value" field of an mLDP FEC (Forwarding Equivalence Class) element. 104 When an IP multicast tree (either a source-specific tree or a 105 bidirectional tree) enters the MPLS network the (S,G) or (*,G) 106 information from the IP multicast control plane state is carried in 107 the opaque value field of the mLDP FEC message. As the tree leaves 108 the MPLS network, this information is extracted from the FEC element 109 and used to build the IP multicast control plane. PIM messages can 110 be sent outside the MPLS domain. Note that although the PIM control 111 messages are sent periodically, the mLDP messages are not. 113 Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in 114 the MPLS network. A network operator should expect to see as many 115 LSPs in the MPLS network as there are IP multicast trees. A network 116 operator should be aware how IP multicast state is created in the 117 network to ensure it does not exceed the scalability numbers of the 118 protocol, either PIM or mLDP. 120 1.1. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 1.2. Terminology 128 IP multicast tree : An IP multicast distribution tree identified by 129 a IP multicast Group address and optionally a Source IP address, 130 also referred to as (S,G) and (*,G). 132 RP: The PIM Rendezvous Point. 134 SSM: PIM Source Specific Multicast. 136 ASM: PIM Any Source Multicast. 138 mLDP : Multipoint LDP. 140 Transit LSP : A P2MP or MP2MP LSP whose FEC element contains the 141 (S,G) or (*,G) identifying a particular IP multicast distribution 142 tree. 144 In-band signaling : Using the opaque value of a mLDP FEC element to 145 carry the (S,G) or (*,G) identifying a particular IP multicast 146 tree. 148 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 149 LSRs. 151 MP2MP LSP: An LSP that connects a set of leaf nodes that may each 152 independently act as ingress or egress. 154 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 156 Ingress LSR: Source of the P2MP LSP, also referred to as root node. 158 Egress LSR: One of potentially many destinations of an LSP, also 159 referred to as leaf node in the case of P2MP and MP2MP LSPs. 161 Transit LSR: An LSR that has one or more directly connected 162 downstream LSRs. 164 2. In-band signaling for MP LSPs 166 Consider the following topology; 167 |--- IPM ---|--- MPLS --|--- IPM ---| 169 S/RP -- (A) - (U) - (C) - (D) -- (B) -- R 171 Figure 1. 173 Nodes A and B are IP Multicast capable routers and respectively 174 connect to a Source/RP and a Receiver. Nodes U, C and D are MPLS 175 Label Switched Routers (LSRs). 177 Label Switched Router D is attached to a network that is capable of 178 MPLS multicast and IP multicast (see figure 1), and D is required to 179 create a IP multicast tree due to a certain IP multicast event, like 180 a PIM Join, MSDP Source Announcement (SA) [RFC3618], BGP Source 181 Active auto-discovery route [I-D.rekhter-pim-sm-over-mldp] or 182 Rendezvous Point (RP) discovery. Suppose that D can determine that 183 the IP multicast tree needs to travel through the MPLS network until 184 it reaches LSR U. For instance, when D looks up the route to the 185 Source or RP [RFC4601] of the IP multicast tree, it may discover that 186 the route is a BGP route with U as the BGP next hop. Then D may 187 chose to set up a P2MP or MP2MP LSP, with U as root, and to make that 188 LSP become part of the IP multicast distribution tree. Note that 189 other methods are possible to determine that an IP multicast tree is 190 to be transported across an MPLS network using P2MP or MP2MP LSPs, 191 these methods are outside the scope of this document. 193 In order to establish a multicast tree via a P2MP or MP2MP LSP using 194 "in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with 195 the IP address of LSR U as the "Root Node Address", and with the 196 source and the group encoded into the "opaque value" ([RFC6388], 197 section 2.2 and 3.2). Several different opaque value types are 198 defined in this document; LSR D MUST NOT use a particular opaque 199 value type unless it knows (through provisioning, or through some 200 other means outside the scope of this document) that LSR U supports 201 the root node procedures for that opaque value type. 203 The particular type of FEC Element and opaque value used depends on 204 the IP address family being used, and on whether the multicast tree 205 being established is a source specific or a bidirectional multicast 206 tree. 208 When an LSR receives a label mapping or withdraw whose FEC Element 209 contains one of the opaque value types defined in this document, and 210 that LSR is not the one identified by the "Root Node Address" field 211 of that FEC element, the LSR follows the procedures of RFC 6388. 213 When an LSR receives a label mapping or withdraw whose FEC Element 214 contains one of the opaque value types defined in this document, and 215 that LSR is the one identified by the "Root Node Address" field of 216 that FEC element, then the following procedure is executed. The 217 multicast source and group are extracted and passed to the multicast 218 code. If a label mapping is being processed, the multicast code will 219 add the downstream LDP neighbor to the olist of the corresponding 220 (S,G) or (*,G) state, creating such state if it does not already 221 exist. If a label withdraw is being processed, the multicast code 222 will remove the downstream LDP neighbor from the olist of the 223 corresponding (S,G) or (*,G) state. From this point on normal PIM 224 processing will occur. 226 Note that if the LSR identified by the "Root Node Address" field does 227 not recognize the opaque value type, the MP LSP will be established, 228 but the root node will not send any multicast data packets on it. 230 Source or RP addresses that are reachable in a VPN context are 231 outside the scope of this document. 233 Multicast groups that operate in PIM Dense-Mode are outside the scope 234 of this document. 236 2.1. Transiting Unidirectional IP multicast Shared Trees 238 Nothing prevents PIM shared trees, used by PIM-SM in the ASM service 239 model, from being transported across a MPLS core. However, it is not 240 possible to prune individual sources from the shared tree without the 241 use of an additional out-of-band signaling protocol, like PIM or BGP 242 [I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared 243 Trees across a Transit LSP is outside the scope of this document. 245 2.2. Transiting IP multicast source trees 247 IP multicast source trees can either be created via PIM operating in 248 SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM 249 mode, the usual means of discovering active sources is to join a 250 sparse mode shared tree. However, this document does not provide any 251 method of establishing a sparse mode shared tree across an MPLS 252 network. To apply the technique of this document to PIM-SM in ASM 253 mode, there must be some other means of discovering the active 254 sources. One possible means is the use of MSDP [RFC3618]. Another 255 possible means is to use BGP Source Active auto-discovery routes, as 256 documented in [I-D.rekhter-pim-sm-over-mldp]. However, the method of 257 discovering the active sources is outside the scope of this document, 258 and as a result this document does not specify everything that is 259 needed to support the ASM service model using in-band signaling. 261 The source and group addresses are encoded into the a transit TLV as 262 specified in Section 3.1 and Section 3.2. 264 2.3. Transiting IP multicast bidirectional trees 266 If a Bidirectional IP multicast trees [RFC5015] has to be transported 267 over a MPLS network using in-band signaling, as described in this 268 document, it MUST be transported using a MP2MP LSPs. A bidirectional 269 tree does not have a specific source address; the group address, 270 subnet mask and RP are relevant for multicast forwarding. This 271 document does not provide procedures to discover RP to group mappings 272 dynamically across an MPLS network and assumes the RP is statically 273 defined. Support of dynamic RP mappings in combination with in-band 274 signaling is outside the scope of his document. 276 The RP for the group is used to select the ingress LSR and root of 277 the LSP. The group address is encoded according to the rules of 278 Section 3.3 or Section 3.4, depending on the IP version. The subnet 279 mask associated with the bidirectional group is encoded in the 280 Transit TLV. There are two types of bidirectional states in IP 281 multicast, the group specific state and the RP state. The first type 282 is typically created due to receiving a PIM join and has a subnet 283 mask of 32 for IPv4 and 128 for IPv6. The latter is typically 284 created via the static RP mapping and has a variable subnet mask. 285 The RP state is used to build a tree to the RP and used for sender 286 only branches. Each state (group specific and RP state) will result 287 in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be 288 done by PIM on the root LSR. No special procedures are necessary for 289 PIM to merge the two LSPs, each LSP is effectively treated as a PIM 290 enabled interface. Please see [RFC5015] for more details. 292 For transporting the packets of a sender only branch we create a 293 MP2MP LSP. Other sender only branches will receive these packets and 294 will not forward them because there are no receivers. These packets 295 will be dropped. If that affect is undesireable some other means of 296 transport has to be established to forward packets to the root of the 297 tree, like a Multi-Point to Point LSP for example. A technique to 298 unicast packets to the root of a P2MP or MP2MP LSP is documented in 299 [I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1. 301 3. LSP opaque encodings 303 This section documents the different transit opaque encodings. 305 3.1. Transit IPv4 Source TLV 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | Source | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | Group | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Type: 3 (to be assigned by IANA). 318 Length: 8 (octet size of Source and Group fields) 320 Source: IPv4 multicast source address, 4 octets. 322 Group: IPv4 multicast group address, 4 octets. 324 3.2. Transit IPv6 Source TLV 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type | Length | Source ~ 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 ~ | Group ~ 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ~ | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Type: 4 (to be assigned by IANA). 338 Length: 32 (octet size of Source and Group fields) 340 Source: IPv6 multicast source address, 16 octets. 342 Group: IPv6 multicast group address, 16 octets. 344 3.3. Transit IPv4 bidir TLV 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | Mask Len | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | RP | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Group | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Type: 5 (to be assigned by IANA). 358 Length: 9 (octet size of Mask Len, RP and Group fields) 360 Mask Len: The number of contiguous one bits that are left justified 361 and used as a mask, 1 octet. Maximum value allowed is 32. 363 RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4 364 octets. 366 Group: IPv4 multicast group address, 4 octets. 368 3.4. Transit IPv6 bidir TLV 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | Mask Len | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | RP ~ 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 ~ | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Group ~ 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 ~ | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Type: 6 (to be assigned by IANA). 386 Length: 33 (octet size of Mask Len, RP and Group fields) 388 Mask Len: The number of contiguous one bits that are left justified 389 and used as a mask, 1 octet. Maximum value allowed is 128. 391 RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 392 octets. 394 Group: IPv6 multicast group address, 16 octets. 396 4. Security Considerations 398 The same security considerations apply as for the base LDP 399 specification, as described in [RFC5036]. 401 5. IANA considerations 403 This document requires allocation from the 'LDP MP Opaque Value 404 Element basic type' name space managed by IANA. The values requested 405 are: 407 Transit IPv4 Source TLV type - 3 409 Transit IPv6 Source TLV type - 4 411 Transit IPv4 Bidir TLV type - 5 413 Transit IPv6 Bidir TLV type - 6 415 6. Acknowledgments 417 Thanks to Eric Rosen for his valuable comments on this document. 418 Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa 419 Andersson and Arkadiy Gulko for providing comments on this document. 421 7. Contributing authors 423 Below is a list of the contributing authors in alphabetical order: 425 Toerless Eckert 426 Cisco Systems, Inc. 427 170 Tasman Drive 428 San Jose, CA, 95134 429 USA 430 E-mail: eckert@cisco.com 432 Nicolai Leymann 433 Deutsche Telekom 434 Winterfeldtstrasse 21 435 Berlin, 10781 436 Germany 437 E-mail: n.leymann@telekom.de 439 Maria Napierala 440 AT&T Labs 441 200 Laurel Avenue 442 Middletown, NJ 07748 443 USA 444 E-mail: mnapierala@att.com 446 IJsbrand Wijnands 447 Cisco Systems, Inc. 448 De kleetlaan 6a 449 1831 Diegem 450 Belgium 451 E-mail: ice@cisco.com 453 8. References 455 8.1. Normative References 457 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 458 Specification", RFC 5036, October 2007. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 464 "Label Distribution Protocol Extensions for Point-to- 465 Multipoint and Multipoint-to-Multipoint Label Switched 466 Paths", RFC 6388, November 2011. 468 8.2. Informative References 470 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 471 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 472 Protocol Specification (Revised)", RFC 4601, August 2006. 474 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 475 IP", RFC 4607, August 2006. 477 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 478 "Bidirectional Protocol Independent Multicast (BIDIR- 479 PIM)", RFC 5015, October 2007. 481 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 482 Protocol (MSDP)", RFC 3618, October 2003. 484 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 485 VPNs", RFC 6513, February 2012. 487 [I-D.rekhter-pim-sm-over-mldp] 488 Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode 489 Trees over P2MP mLDP LSPs", 490 draft-rekhter-pim-sm-over-mldp-04 (work in progress), 491 August 2011. 493 [I-D.rosen-l3vpn-mvpn-mspmsi] 494 Cai, Y., Rosen, E., Wijnands, I., Napierala, M., and A. 495 Boers, "MVPN: Optimized use of PIM via MS-PMSIs", 496 draft-rosen-l3vpn-mvpn-mspmsi-10 (work in progress), 497 February 2012. 499 Authors' Addresses 501 IJsbrand Wijnands (editor) 502 Cisco Systems, Inc. 503 De kleetlaan 6a 504 Diegem 1831 505 Belgium 507 Email: ice@cisco.com 508 Toerless Eckert 509 Cisco Systems, Inc. 510 170 Tasman Drive 511 San Jose CA, 95134 512 USA 514 Email: eckert@cisco.com 516 Nicolai Leymann 517 Deutsche Telekom 518 Winterfeldtstrasse 21 519 Berlin 10781 520 Germany 522 Email: n.leymann@telekom.de 524 Maria Napierala 525 AT&T Labs 526 200 Laurel Avenue 527 Middletown NJ 07748 528 USA 530 Email: mnapierala@att.com