--- 1/draft-ietf-opsawg-lsn-deployment-04.txt 2014-01-22 19:14:33.794363718 -0800 +++ 2/draft-ietf-opsawg-lsn-deployment-05.txt 2014-01-22 19:14:33.838364835 -0800 @@ -1,18 +1,18 @@ OPSAWG V. Kuarsingh, Ed. Internet-Draft J. Cianfarani Intended status: Informational Rogers Communications -Expires: June 26, 2014 December 23, 2013 +Expires: July 27, 2014 January 23, 2014 CGN Deployment with BGP/MPLS IP VPNs - draft-ietf-opsawg-lsn-deployment-04 + draft-ietf-opsawg-lsn-deployment-05 Abstract This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may @@ -20,88 +20,87 @@ term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. -Status of This Memo +Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on June 26, 2014. + This Internet-Draft will expire on July 27, 2014. Copyright Notice - - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Existing Network Considerations . . . . . . . . . . . . . . . 5 + 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 5 3.1. Centralized versus Distributed Deployment . . . . . . . . 6 - 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 + 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 7 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 7 - 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 - 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 8 - 3.7. Transactional Logging for CGN Systems . . . . . . . . . . 8 - 3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 8 + 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 8 + 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 8 + 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 8 + 3.7. Transactional Logging for CGN Systems . . . . . . . . . . 9 + 3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 9 4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 9 - 4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10 - 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 11 - 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 13 - 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 15 + 4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 11 + 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 12 + 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 14 + 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 16 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN - Attachment Options . . . . . . . . . . . . . . . . . . . 15 - 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 15 - 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 16 - 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 16 - 4.5. Multicast Considerations . . . . . . . . . . . . . . . . 16 - 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Basic Integration and Requirements Support . . . . . . . 16 - 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 18 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 10.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + Attachment Options . . . . . . . . . . . . . . . . . . . . 16 + 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 16 + 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 17 + 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 17 + 4.5. Multicast Considerations . . . . . . . . . . . . . . . . . 17 + 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Basic Integration and Requirements Support . . . . . . . . 17 + 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 18 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . . 18 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Operators are faced with near term IPv4 address exhaustion challenges. Many operators may not have a sufficient amount of IPv4 addresses in the future to satisfy the needs of their growing subscriber base. This challenge may also be present before or during an active transition to IPv6 somewhat complicating the overall problem space. @@ -132,63 +131,49 @@ DOCSIS - Data Over Cable Service Interface Specification CMTS - Cable Modem Termination System DSL -Digital subscriber line BRAS - Broadband Remote Access Server GGSN - Gateway GPRS Support Node + GPRS - General Packet Radio Service ASN-GW - Access Service Network Gateway + GRT - Global Routing Table -2. Motivation + Internal Realm - Addressing and/or network zone been the CPE and + CGN as specified in [RFC6888] - The selection of CGN may be made by an operator based on a number of - factors. The overall driver may be the depletion of IPv4 address - pools which leaves little to no addresses for IPv4 service or - connection demand growth. IPv6 is considered the strategic answer, - but it's applicability and usefulness in many networks is limited by - the current access network and consumer home network. Customer - environments often are filled with IPv4-only equipment which may not - be upgradable to IPv6. + External Realm - Public side network zone and addressing on the + Internet facing side of the CGN as specified in [RFC6888] - The ability to replace IPv4-only equipment may be out of the control - of the operator, and even when it's in the administrative control, it - poses both cost and technical challenges as operators build out - massive programs for equipment retirement or upgrade. These issues - leave an operator in a precarious position which may lead to the - decision to deploy CGN. Other address IPv4 sharing options do exist - which are more architecturally desirable, but the practical and - workable approach in many cases is a CGN deployment using the NAT444 - framework. +2. Existing Network Considerations + + The selection of CGN may be made by an operator based on a number of + factors. The overall driver to use CGN may be the depletion of IPv4 + address pools which leaves little to no addresses for a growing IPv4 + service or connection demand growth. IPv6 is considered the + strategic answer for IPv4 address depletion; however, the operator + may independently decide that CGN is needed to supplement IPv6 and + address their particular IPv4 service deployment needs. If the operator has chosen to deploy CGN, they should do this in a manner as not to negatively impact the existing IPv4 or IPv6 subscriber base. This will include solving a number of challenges since subscribers whose connections require translation will have network routing and flow needs which are different from legacy IPv4 connections. - The solution will also need to work in a dual stack environment where - other options such as DS-Lite [RFC6333] are not yet viable. Even - technologies like 6RD [RFC5969] still require an IPv4 connectivity - path to service the subscriber endpoint. The solution will need to - address basic Internet connectivity, on-net service offerings, back - office management, billing, policy and security models already in - place within the operator's network. CGN will often integrate quite - readily with the aforementioned requirements where as other - transition mechanism may not due to the requirements to support IPv6 - as the base protocol for IPv4 connectivity. - 3. CGN Network Deployment Requirements If a service provider is considering a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements which are of importance. Preliminary architectural requirements may require all or some of those captured in the list below. Each of the architectural requirement items listed are expanded upon in the following subsections. It should be noted that architectural CGN requirements add additive to base CGN functional requirements in [RFC6888]. The assessed architectural requirements @@ -236,22 +220,22 @@ extend possible; Other requirements may be assessed on a operator-by-operator basis, but those listed above may be considered for any given deployment architecture. 3.1. Centralized versus Distributed Deployment Centralized deployments of CGN (longer proximity to end user and/or higher densities of subscribers/connections to CGN instances) differ - from distributed deployments of CGN (closer proximity to end user and - /or lower densities of subscribers/connections to CGN instances). + from distributed deployments of CGN (closer proximity to end user + and/or lower densities of subscribers/connections to CGN instances). Service providers may likely deploy CGN translation points more centrally during initial phases if the early system demand is low. Early deployments may see light loading on these new systems since legacy IPv4 services will continue to operate with most endpoints using globally unique IPv4 addresses. Exceptional cases which may drive heavy usage in initial stages may include operators who already translate a significant portion of their IPv4 traffic; may transition to a CGN implementation from legacy translation mechanisms (i.e. traditional firewalls); or build a green field deployment which may see quick growth in the number of new IPv4 endpoints which require @@ -347,63 +331,62 @@ subscriber base . The CGN deployment should provide mechanisms to manage IPv4 overlap if required. 3.7. Transactional Logging for CGN Systems CGNs may require transactional logging since the source IP and related transport protocol information is not easily visible to external hosts and system. If needed, the CGN systems should be able to generate logs which - identify 'internal' host parameters (i.e. IP/Port) and associated - them to external translated parameters imposed by the translator. - The logged information should be stored on the CGN hardware and/or - exported to an external system for processing. The operator may - choose to also enable mechanisms to help reduce logging such as block - allocation of UDP and TCP ports or deterministic translation options - such as [I-D.donley-behave-deterministic-cgn]. + identify internal realm host parameters (i.e. IP/Port) and + associated them to external realm parameters imposed by the + translator. The logged information should be stored on the CGN + hardware and/or exported to another system for processing. The + operator may choose to also enable mechanisms to help reduce logging + such as block allocation of UDP and TCP ports or deterministic + translation options such as [I-D.donley-behave-deterministic-cgn]. Operators may need to keep track of this information (securely) to meet regulatory and/or legal obligations. Further information can be found in [RFC6888] with respect to CGN logging requirements (Logging Section). 3.8. Base CGN Requirements Whereas the requirements above represent assessed architectural requirements, the CGN platform will also need to meet the need to meet the base CGN requirements of a CGN function. Base requirements include such functions as Bulk Port Allocation and other CGN device specific functions. These base CGN platform requirements are captured within [RFC6888]. 4. BGP/MPLS IP VPN based CGN Framework - The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre- - translated' realms within the service provider space into Layer-3 - MPLS based VPNs. The operator can deploy a single realm for all CGN - based flows, or can deploy multiple realms based on translation - demand and other factors such as geographical proximity. A realm in - this model refers to a 'VPN' which shares a unique Route - Distinguisher/Route Target (RD/RT) combination, routing plane and - forwarding behaviours. + The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the + internal realms within the service provider space into Layer-3 MPLS + based VPNs. The operator can deploy a single realm for all CGN based + flows, or can deploy multiple realms based on translation demand and + other factors such as geographical proximity. A realm in this model + refers to a 'VPN' which shares a unique Route Distinguisher/Route + Target (RD/RT) combination, routing plane and forwarding behaviours. The BGP/MPLS IP VPN infrastructure provides control plane and forwarding separation for the traditional IPv4 service environment and CGN environment(s). The separation allows for routing information (such as default routes) to be propagated separately for CGN and non-CGN based subscriber flows. Traffic can be efficiently routed to the Internet for normal flows, and routed directly to translators for CGN mediated flows. Although many operators may run a "default-route-free" core, IPv4 flows which require translation must obviously be routed first to a translator, so a default route is - acceptable for the pre-translated realms. + acceptable for the internal realms. The physical location of the Virtual Routing and Forwarding (VRF) Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be located anywhere within the operator's network. This model fully virtualizes the translation service from the base IPv4 forwarding environment which will likely be carrying Internet bound traffic. The base IPv4 environment can continue to service traditional IPv4 subscriber flows plus post translated CGN flows. Figure 1 provides a view of the basic model. The Access node @@ -425,43 +408,45 @@ Access Node VRF Termination CGN +-----------+ +-----------+ +-----------+ | | | | | | CPE | +-------+ | | +-------+ | | +-------+ | +----+ | | | | LSP | | | | IP | | | | | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | +----+ | | | | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | | | XLATE | | | | | | | | | | - CPE | +-------+ | | +-------+ | | | | | + CPE-CGN | +-------+ | | +-------+ | | | | | +----+ | | | | | | | | IP | | | | | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | +----+ | | | | | | | | | | | | | | | +---+---+ | | +---+---+ | | +-------+ | +-----+-----+ +-----+-----+ +-----------+ | | | | IPv4 | | IP +---------+ | +------------+-> | | IP | GRT | +------------------------------+-> | +---------+ Figure 1: Basic BGP/MPLS IP VPN CGN Model If more then one VRF (translation realm) is used within the operator's network, each VPN instance can manage CGN flows - independently for the respective realm. Various redundancy models - can be used within this architecture to support failover from one - physical CGN hardware instance to another. If state information - needs to be passed or maintained between hardware instances, the - vendor would need to enable this feature in a suitable manner. + independently for the respective realm. The described architecture + does not prescribe a single redundancy model that ensures network + availability as a result of CGN failure. Deployments are able to + select a redundancy model that fits best with their network design. + If state information needs to be passed or maintained between + hardware instances, the vendor would need to enable this feature in a + suitable manner. 4.1. Service Separation The MPLS/VPN CGN framework supports route separation. The traditional IPv4 flows can be separated at the access node (Initial Layer 3 service point) from those which require translation. This type of service separation is possible on common technologies used for Internet access within many operator networks. Service separation can be accomplished on common access technology including those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile @@ -512,21 +497,21 @@ Access Node VRF Termination CGN +-------------+ +-----------+ +----------+ | | | | | | CPE | +---------+ | | +-------+ | | +------+ | +-----+ | | | | | | | | | | | | | --+--+-+-> VRF --+-+--+ | | VRF | | | | | | +-----+ | | | | | | | | | | | | | | +---------+ | | | +-------+ | | | | | | | | | | | |XLATE | | | | | | | | | | | - CPE | +---------+ | | | +-------+ | | | | | + CPE-CGN | +---------+ | | | +-------+ | | | | | +-----+ | | | | | | | | | | | | | | --+--+-+-> GRT | | | | | GRT | | | | | | +-----+ | | | | | | | | | | | | | | | +----+----+ | | | +-------+ | | +------+ | +------+------+ | +-----------+ +----------+ | | | | IPv4 | | +-----------+ | +---------------+->Services | | | VRF | @@ -538,47 +523,47 @@ | Local | | Content | +-----------+ Figure 2: Internal Services and CGN By-Pass An extension to the services delivery LSP is the ability to also provide direct subscriber to subscriber traffic flows between CGN zones. Each zone or realm may be fitted with separate CGN resources, but the subtending subscribers don't necessarily need to be mediated - (translated) by the CGN translators. This option, as shown in - Figure 3 below, is easy to implement and can only be enabled if no - IPv4 address overlap is used between communicating CGN zones. + (translated) by the CGN translators. This option, as shown in Figure + 3 below, is easy to implement and can only be enabled if no IPv4 + address overlap is used between communicating CGN zones. Access Node-1 VRF Termination CGN-1 +-------------+ +-----------+ +----------+ | | | | | | CPE-1 | +---------+ | | +-------+ | | +------+ | +-----+ | | | | | | | | | | | | | --+--+-+- VRF --+-+-+ | | VRF | | | | | | +-----+ | | | | | | | | | | | | | | +---------+ | | | +-------+ | | | | | | | | | | | |XLATE | | | | | | | | | | | - CPE-2 | +---------+ | | | +-------+ | | | | | + CPE-2-CGN| +---------+ | | | +-------+ | | | | | +-----+ | | | | | | | | | | | | | | --+--+-+- GRT | | | | | GRT | | | | | | +-----+ | | | | | | | | | | | | | | +---------+ | | | +-------+ | | +------+ | +-------------+ | +-----------+ +----------+ | LSP | | Access Node-2 | VRF Termination CGN-2 +-------------+ | +-----------+ +----------+ | | | | | | | - CPE-3 | +---------+ | | | +-------+ | | +------+ | + CPE-3-CGN| +---------+ | | | +-------+ | | +------+ | +-----+ | | | | | | | | | | | | | | --+--+-+-- VRF --+-+-+ | | VRF | | | | | | +-----+ | | | | | | | | | | | | | +---------+ | | +-------+ | | | | | | | | | | |XLATE | | | | | | | | | | CPE-4 | +---------+ | | +-------+ | | | | | +-----+ | | | | | | | | | | | | | --+--+-+- GRT | | | | GRT | | | | | | +-----+ | | | | | | | | | | | | @@ -608,21 +593,21 @@ The Figure 4 below shows how IPv4 translation services can be provided alongside IPv6 based services. The model shown allows the provider to enable CGN to manage IPv4 flows (translated) and IPv6 flows are routed without translation efficiently towards the Internet. Once again, forwarding of flows to the translator does not impact IPv6 flows which do not require this service. Access Node VRF Termination CGN +-----------+ +-----------+ +-----------+ | | | | | | - CPE | +-------+ | | +-------+ | | +-------+ | + CPE-CG | +-------+ | | +-------+ | | +-------+ | +-----+ | | | |LSP| | | | IP | | | | | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | |IPv4 | | | | | | | | | | | | | | | | +-------+ | | +-------+ | | | | | +-----| | | | | | | XLATE | | |IPv6 | | | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | IPv6 | | | | IPv4 | | IP | | | | | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | +-----+ | | | | | | | | | | | | | | @@ -762,38 +747,26 @@ 5.2. Performance The MPLS/VPN CGN model was observed to support basic functions which are typically used by subscribes within an operator environment. A full review of the observed impacts related to CGN (NAT444) are covered in [RFC7021]. 6. IANA Considerations - There are not specific IANA considerations known at this time with - the architecture described herein. Should a provide choose to use - non-assigned IP address space within their translation realms, then - considerations may apply. + This document has no IANA actions. 7. Security Considerations The same security considerations would typically exist for CGN - deployments when compared with traditional IPv4 based services. With - the MPLS/VPN model, the operator would want to consider security - issues related to offering IP services over MPLS. - - If a provider plans to operate the pre-translation realm (CPE towards - translator IPv4 zone) as a non-public like network, then additional - security measures may be needed to secure this environment. It is - however the position in this document that CGN realms are public - domains which utilize non-Internet routable IP addresses for endpoint - addressing. + deployments when compared with traditional IPv4 based services. 8. BGP/MPLS IP VPN CGN Framework Discussion The MPLS/VPN delivery method for a CGN deployment is an effective and scalable way to deliver mass translation services. The architecture avoids the complex requirements of traffic engineering and policy based routing when combining these new service flows to existing IPv4 operation. This is advantageous since the NAT44/CGN environments should be introduced with as little impact as possible and these environments are expected to change over time. @@ -818,36 +791,37 @@ 10.1. Normative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 10.2. Informative References [I-D.donley-behave-deterministic-cgn] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce - Logging in Carrier Grade NAT Deployments", draft-donley- - behave-deterministic-cgn-06 (work in progress), July 2013. + Logging in Carrier Grade NAT Deployments", + draft-donley-behave-deterministic-cgn-06 (work in + progress), July 2013. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and - E. Lear, "Address Allocation for Private Internets", BCP - 5, RFC 1918, February 1996. + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 - Infrastructures (6rd) -- Protocol Specification", RFC - 5969, August 2010. + Infrastructures (6rd) -- Protocol Specification", + RFC 5969, August 2010. [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental