INTERNET-DRAFT Paul Unbehagen Intended Status: Informational Roger Lapuh Expires: September 6, 2012 Avaya Sue Hares Peter Ashwood-Smith Hauwei March 5, 2012 IP/IPVPN services with IEEE 802.1aq SPB networks draft-unbehagen-spb-ip-ipvpn-00.txt Abstract This document describes a compact method of using a IEEE 802.1aq Shortest Path Backbone Bridging (SPB) network to natively enable and carry IP and IPVPN services on native Ethernet links. Further this documents the extensions to SPB's control protocol, IS-IS, required to allow it to be a single mechanism for providing all these services types. On its own SPB provides virtual Ethernet networks; utilizing IS-IS to create loop free Ethernet topologies that forward Ethernet traffic using a standard Ethernet header. This document shows how the same SPB network can also be leveraged to provide IP based services. Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Unbehagen et al Expires September 6, 2012 [Page 1] INTERNET DRAFT IP/SPB March 5, 2012 Copyright and License Notice Copyright (c) 2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SPB control of BMAC forwarding . . . . . . . . . . . . . . . . 4 3. IP forwarding with SPB . . . . . . . . . . . . . . . . . . . . 5 3.1. IP Unicast . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IPVPN services with SPB . . . . . . . . . . . . . . . . . . . . 6 4.1. Route Propagation Techniques . . . . . . . . . . . . . . . 6 4.2. Ethernet underlay modes - 802.1aq and/or 802.1Qbp . . . . . 8 4.3. I-TAG Encapsulation . . . . . . . . . . . . . . . . . . . . 9 5. Interworking with MPLS based Networks . . . . . . . . . . . . . 10 6. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Unbehagen et al Expires September 6, 2012 [Page 2] INTERNET DRAFT IP/SPB March 5, 2012 1 Introduction The IEEE has defined a method for L2 virtualization called Shortest Path Bridging (SPB), which is leveraging IS-IS as a new Ethernet control plane to control the BMAC layer of the 802.1ah PBB encapsulation, replacing Ethernet's flooding and learning as the backbone forwarding protocol. In addition to layer 2 (bridging), the 24 bits of the Service Instance defined in the 802.1ah frame format can also be leveraged for any network connectivity service including layer 3 Unicast and Multicast for IPv4 and IPv6. This document outlines the proposed extensions to ISIS-SPB to enable this functionality. The benefits of leveraging one protocol (ISIS-SPB) to provide any type of connectivity service on top of Ethernet are significant. SPB, through the use of ISIS to exchange the connectivity service topology, provides a powerful end-point-only provisioning model. IP/SPB leverages this and extends this to Layer 3, thus not only L2 VPNs can be formed by attaching Virtual LANs to service IDs (ISIDs), but also L3 VPNs can be formed by binding Virtual Route Forwarders (VRFs) to ISIDs at the service attachment points. Due to the fact that all connectivity services described above are using the same SPB forwarding plane defined in IEEE802.1aq/.1Qbp, network availability is defined by the convergence timing of the single ISIS-SPB control plane. 1.1 Terminology 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 RFC 2119 [RFC2119]. [IEEE802.1aq] defines a technology for providing a link state protocol for the control of a common Ethernet switching layer. [IEEE802.1ah] Provider Backbone Bridging is a set of architecture and protocols for transporting of a customer network traffic over a provider's network BCB - Backbone Core Bridge BDA - Backbone Destination Address BEB - Backbone Edge Bridge BMAC - Backbone MAC Address Unbehagen et al Expires September 6, 2012 [Page 3] INTERNET DRAFT IP/SPB March 5, 2012 BSA - Backbone Source Address BVID - Backbone VLAN ID ESP - Ethernet Switched Path ISID - Service Identifier ISIS - Intermediate System to Intermediate System Routing Protocol ISIS-SPB - ISIS extensions for SPB MDT - Multicast Distribution Tree SPF - Shortest Path Forwarding SPB - Shortest Path Bridging TLV - Type Length Value VLAN - Virtual LAN 2. SPB control of BMAC forwarding SPB uses the terms Backbone Core Bridge (BCB) and Backbone Edge Bridge (BEB) to describe the functions of network nodes in the network. These terms describe features that are similar in function to the PE and P nodes in an MPLS network. SPB enables a loop free construction of Ethernet switched paths between every SPB enabled node by reusing some existing components of IS-IS and by adding a small set of new IS-IS TLVs. SPB nodes use a standard IS-IS mechanism of operation for neighbor discovery and database distribution. SPB utilizes an IS-IS based on IS-IS Ethernet link level peering protocol so it does not depend on link level IP addressing. Also, due to the fact that the links are forwarding on the source and destination information in the Ethernet header, there is no requirement to verify that each node can do IP routing. Multicast Forwarding entries (BMAC FDB or FIB) on each node are constructed based on a combination of a nodal unique identifier and a administratively controlled service identifier providing multicast trees that can be adjusted to match a desired service granularity. Each node uses standard IS-IS methods of sharing link state PDU's. Those PDUs contain the System-ID of each node, the attached neighbors and information such as EVPN ISIDs for SPB. A unicast SPF process runs on each switch to construct the unicast connectivity of each Unbehagen et al Expires September 6, 2012 [Page 4] INTERNET DRAFT IP/SPB March 5, 2012 switch to every other switch based on these nodal MAC's (BMACs) derived from the System-ID. Each node that is on the shortest path between any other given nodes will install corresponding FDB entries only on their associated ports. This has the added benefit that Ethernet FDB entries exist only on nodes that are the source, root, or tandem point for a give SPF ESP between any given set of nodes. Any node that does not need to participate in the tandem calculations may use the IS-IS overload bit to exclude tandem paths and behave as only the root or source for any given service traffic. 3. IP forwarding with SPB IP unicast and multicast can leverage this base BMAC switching layer by mapping IP to the Ethernet service points. For unicast forwarding the standard mechanisms of IS-IS IP route propagation can be used to associate remote IP networks to the far end nodal Ethernet address. The encapsulation of IP unicast packets would use the standard method to include an Ethertype of 0x800 behind the BMAC header. Packets received Packets in transit Packets forwarded at ingress BEB in the network by egress BEB +============+ +=============+ +============+ | IP Header | | IP Header | | IP Header | +============+ >>>>> +=============+ >>>>> +============+ | C-MAC | | B-MAC | | C-MAC | +============+ +=============+ +============+ 3.1. IP Unicast The native unicast entries SPB constructs, provide a simple way of enabling end to end switching of IP packets along a deterministic Ethernet Switched Path (ESP). Knowledge of the location of IP subnet's is achieved by utilizing the existing functionality of IS-IS TLVs for IPv4 and IPv6. The control plane operation becomes one of simply creating FDB entries that map IP routes to their points of presence. In other words the FDB entry for an IP route simply gives the last hop BMAC of the BEB which advertised that route. No shortest path computations are required since that has already been accomplished by the SPB layer. For IP subnet awareness the existing IS-IS TLVs are used to propagate routes. The encapsulation is the standard IP in Ethernet encapsulation. To enable this behavior, this document specifies an efficient learning and forwarding operation where an edge BEB provides a Unbehagen et al Expires September 6, 2012 [Page 5] INTERNET DRAFT IP/SPB March 5, 2012 standard IP interface to its attached IP devices. The BEB performs a route lookup on the destination IP addresses which will resolve to a remote BMAC to forward towards on the SPB portion of the network, and then encapsulates the IP packet in a Ethernet header using the unicast BMAC operation with a standard IPv4 or IPv6 Ethertype. In essence this is IP over Ethernet where the Ethernet is a BMAC based Ethernet. One simple way to think of this is that existing ISIS for IP implementations forward IP packets to the next hop router, while this mechanism forwards an IP packet directly to the last hop BEB within the SPB domain thereby eliminating IP forwarding operations on tandem devices. 4. IPVPN services with SPB Using the TLV extensions described below it is possible to extend SPB to not only provide EVPN and the above described IP connectivity, but also provide virtualized solutions for IP services such as IPVPNs. The next sections will outline the route propagation techniques for two different deployment models. Two common modes of carrying information are: BGP or ISIS [ISIS]. The IS-IS method will be described in this version of the draft. The control plane encapsulation of VRF routes passed in BGP is similar to the method used here with ISIS. 4.1. Route Propagation Techniques The ability to share routes within a network can be provided within IS-IS. To accomplish this flexibility the use of a new IPVPN TLV and an optional sub-TLV is proposed. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| MT-ID |U|Resv | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R| Resv |S| ISID Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 IPVPN TLV The TLV MAY appear any number of times (including none) within a Link State PDU. The up/down bit used for notification if this TLV has been leaked down into a L1. The T bit and R bit are used to signal to the other nodes whether to construct Multicast trees to and from this announcing node depending on the combination of bits set to 1. If neither the T nor R bit is Unbehagen et al Expires September 6, 2012 [Page 6] INTERNET DRAFT IP/SPB March 5, 2012 set, then the IPVPN service is unicast only. The next 4 bits are reserved and the S bit is used to signify that the VPN-Route Sub-TLVs are present. Sub-TLVs may be set to carry specific routes for each VPN within IS- IS. This allows for routes from multiple VPNs to be carried under their respective VPN ISID IDs and allow for overlapping IP subnet's. IP/SPB VPN ISIDs are comparable to RFC4364 Route distinguishers and route targets to separate VPN traffic in the control plane. VPN routes are exchanged through IS-IS and can be distinguished by the individual ISID they are associated with. In order to form different types of IP VPNs on BEB's, routes can be exported into ISID's or imported from ISID's. This document also defines the following new sub-TLV types that need to be reflected in the IS-IS sub-TLV registry for the SPB ipvpn TLV: Sub-Type Description ------- ------------------------------ 1 IPv4 Prefix information 2 IPv6 Prefix information 3 Reserved 4 Reserved The encapsulation is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Sub-TLV model The sub-TLVs are designed to mimic the top level TLVs for IP reachability within the VPN. Allowing for a given VRF to support multiple IP service models within a single VPN-ID. Sub-TLV 1 is similar as the Extended IPv4 TLV 135 and MAY appear multiple times in the same TLV with a data structure consisting of: Unbehagen et al Expires September 6, 2012 [Page 7] INTERNET DRAFT IP/SPB March 5, 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | Resv |S| Prefix Ln | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 IPv4 sub-TLV Sub-TLV 2 is similar to the IPv6 TLV 236 and MAY appear multiple times in the same TLV with a data structure consisting of: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Resv |E|S| Prefix Ln | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 IPv6 sub-TLV 4.2. Ethernet underlay modes - 802.1aq and/or 802.1Qbp Shortest Path Bridging supports two major modes for L2VPNs via 802.1aq [SPB] and 802.1Qbp [ECMP] the behaviors of which may be selected on a per ISID basis for carriage of L3VPNs as follows. The 802.1aq [SPB] L2 underlay on which IPVPN packets flow, supports deterministic and symmetric multiple equal cost routes with hashing to the different routes at the head end via normal IP n-tuple or other micro flow order preserving hash mechanisms. To obtain this behavior the IPVPN TLV VID field MUST contain a BVID value which has been associated with one of the 802.1aq ECT-ALGORITHMS by the SPB underlay in the SPB Base VLAN-Identifiers sub-TLV. This will cause the ISID information which follows to have 802.1aq semantics - i.e. (S,G) multicast and symmetric/congruent routing. The normal 802.1aq ECT-ALGORITHM values 00-80-C2-01 thru 00-80-C2-10 and their associated VIDs are advertised normally in the IIH and LSPs for 802.1aq and the head end IPVPN behavior is free to hash over any or all of those VIDs. Unbehagen et al Expires September 6, 2012 [Page 8] INTERNET DRAFT IP/SPB March 5, 2012 The 802.1Qbp [ECMP] extensions to [SPB] supports a flow-tag with a FlowId and TTL resulting in a per hop hashed choice of next hop by L2 forwarding. To obtain this behavior the IPVPN TLV VID field MUST contain a BVID value which has been associated with one of the 802.1Qbp ECT-ALGORITHMS by the SPB underlay in the SPB Base VLAN- Identifiers sub-TLV. This will cause the ISID information which follows to have 802.1Qbp semantics - i.e. (*,G) and/or (S,G) multicast and non deterministic non symmetric routing. The normal 802.1Qbp ECT-ALGORITHM value 00-80-C2-11 and its associated VIDs are advertised normally in the IIH and LSPs for 802.1Qbp and the head end IPVPN behavior is free to hash over all ECMP L2 next hops for this VID and to insert a flow-tag with appropriate TTL value and FlowId based on the L3 hash result. The TTL and FlowId will then be used to enable tandem .1Qbp ECMP behavior without knowledge of or inspection of the L3VPN headers. 4.3. I-TAG Encapsulation For the forwarding of IPVPN traffic the use of the standard 802.1ah I-TAG would require the encapsulation of a nulled out CMAC address, since the traffic is IP and routed at each BEB there is no need for a CMAC. Therefore the more optimal encapsulated method used for IPVPN traffic within the SPB network is to use the ISID portion of the I- TAG without a CMAC header, called the short I-TAG. This allows the network to carry forward the benefits of the global label/VPN ID purpose of the ISID without enforcing unnecessary header overhead. The encapsulation of IP packets being forwarded for a IPVPN would use a short I-Tag (ISID with no CMAC) behind the BMAC header. While the short I-TAG is the recommended mode for carrying IPVPN traffic this standard permits the inclusion of a zerod out CMAC. In this case the sender MUST zero out the CMAC on transmission and MUST ignore a non- zero CMAC on receipt. Packets received Packets in transit Packets forwarded at ingress BEB VRF in the network by egress BEB VRF +=============+ | IP Header | +============+ +=============+ +============+ | IP Header | | Short I-TAG | | IP Header | +============+ >>>>> +=============+ >>>>> +============+ | C-MAC | | B-MAC | | C-MAC | +============+ +=============+ +============+ Figure 7 Short I-TAG encapsulation of IPVPN Packets Unbehagen et al Expires September 6, 2012 [Page 9] INTERNET DRAFT IP/SPB March 5, 2012 Where the ISID encapsulation is as follows. Directly between the VLAN and IP header. .1ah I-TAG TCI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P/DE |R1 |R2 | I-SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 Short I-Tag P/DE 3 Bits Priority, 1 bit Drop Eligible R1 Res1 R2 Res2 5. Interworking with MPLS based Networks Any IP/SPB and/or IPVPN SPB network may exist on its own or may be part of a larger network. For example it may be attached to a standard IP or IP/MPLS network. This section will define a use case for using an SPB base network as a method of extending IPVPNs from a IP/MPLS core network. A similar model exists for the ELAN service that may span both a SPB and VPLS portions of the network as defined in [PBBVPLS] The scale and size of the SPB portion of the network and network devices can then be utilized more efficiently as a single protocol will drain less resources and thereby allow the IPVPN VRFs extend closer to the end customer. Another benefit is that packets that are destined within the SPB network can be forwarded directly in the SPB portion of the domain without needing to be processed by the MPLS PE. Unbehagen et al Expires September 6, 2012 [Page 10] INTERNET DRAFT IP/SPB March 5, 2012 _,,..--..,,, ,-'` `'-, .` `' ,' `. / , | IP MPLS Core | ` `. ` ', _-` +------/-,, _,-,------+ | ,-,/ | ``'''--'''`` | ,-, | MPLS-PE1 | |VRF| | | |VRF| |MPLS-PE2 | | | | BC-PEs | | | | | `|' | | `|' | +-,--,,-+ +--,--,,+ ,' ,' / / | SPB | | SPB | | Network | | Network | | | | | / / `. / `. / +------`-,,+-------+ +-------+'-'+-------+ | ,-, | | ,-, | | ,-, | | ,-, | | |VRF| | | |VRF| | | |VRF| | | |VRF| | | | | | | | | | BEBs | | | | | | | | | `'' | | `'' | | `'' | | `'' | +-------+ +-------+ +-------+ +-------+ BEB1 BEB2 BEB3 BEB4 Figure 12 MPLS Interworking A vrf does Service Address Encapsulation on a VPN basis with some entries of the VRF having MPLS labels and some have IPVPN SPB entries based on the direction from which the route was learned. The VRF also gets information from different topologies. Routes learned via BGP have FIB entries pointing to the appropriate next hop and Label set. While routes learned from the IPVPN ISID SPB domain have FDB entries for the appropriate BMAC address and ISID. Route propagation to and from each domain happens naturally via the protocol interaction within a given VRF. Routes learned from the SPB domain are automatically announced into the BGP domain or may have policies applied and routes learned from other PE's from BGP are automatically propagated towards the CE's by injecting them into the SPB domain as a sub-TLV under the VRF's IPVPN ISID TLV. Unbehagen et al Expires September 6, 2012 [Page 11] INTERNET DRAFT IP/SPB March 5, 2012 6. OAM Various techniques exist within the Ethernet standards space for scalable management of Ethernet based networks. For example OAM techniques defined in the IEEE 802.ag and the ITU Y.1731 can be used for the IP based services similarly as they are defined for the EVPNs 7. Security Considerations The extensions defined in this document do not incur any additional security considerations. Any IS-IS SPB network may utilize the security enhancements already defined within the IS-IS working group. 8. IANA Considerations IP/SPB requires that IANA/ISO allocate a new number from ISIS-TLV Codepoints for the IPVPN TLV. IP/SPB also requires that IANA/ISO allocate a new registry for sub TLV values within the above TLV. The first four values being: 1 IPV4 2 IPV6 3 reserved 4 reserved 9. References 9.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MTISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [IPVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [802.1AQ] "IEEE P802.1aq/D4.5 Draft Standard for Local and Metropolitan Area Networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks, Amendment 8: Shortest Path Bridging", IEEE 802.1aq D4.5, Feb 6, 2012 [802.1AQ] Ashwood-Smith, P, Fedyk, D., "IS-IS Extensions Supporting IEEEE 802.1aq Shortest Path Bridging" RFC 6329, XXX, 2012. 9.2 Informative References Unbehagen et al Expires September 6, 2012 [Page 12] INTERNET DRAFT IP/SPB March 5, 2012 [IEEE802.1ah] "IEEE Standard for Local and Metropolitan Networks, Virtual Bridged Local Area Networks, Amendment 7: Provider Backbone Bridges" IEEE Std 802.1ah - 2008 amendment to IEEE 802.Q - 2005. [ISIS] ISO/IEC 10589:2002, "Intermediate system to Intermediate system routing information exchange protocol," ISO/IEC10589:2002. [PBBVPLS] Extensions to VPLS PE model for Provider Backbone Bridging, IETF, Internet Draft, draft-ietf-l2vpn-pbb-vpls-pe-model- 00.txt, Work in Progress, May 12 2009 10. Acknowledgments The authors would like to thank Don Fedyk for input into the contents of this document. And also Dave Allan, Nigel Bragg, Gautam Khera, Srikanth Keesara and Harish Sankaran for their detailed review of larger work that is behind this memo. This document was prepared using nroff. Authors' Addresses Paul Unbehagen Jr Avaya 1300 W. 120th Avenue Westminster, CO 80234 USA Email: unbehagen@avaya.com Roger Lapuh Avaya Flughofstrasse 54 8152 Glattbrugg Switzerland Email: rlapuh@avaya.com Peter Ashwood-Smith Huawei Technologies Canada LTD. 303 Terry Fox drive, Suite 400 Kanata, Ontario , K2K 2J1, Canada Email: peter.ashwoodsmith@huawei.com Susan Hares Huawei Email: shares@ndzh.com 1-734-604-0332 Unbehagen et al Expires September 6, 2012 [Page 13] INTERNET DRAFT IP/SPB March 5, 2012 Unbehagen et al Expires September 6, 2012 [Page 14]