[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Requirements for IP Multihoming Architectures
- To: multi6@ops.ietf.org
- Subject: Requirements for IP Multihoming Architectures
- From: Ben Black <ben@layer8.net>
- Date: Mon, 19 Mar 2001 23:55:40 -0800
- Delivery-date: Tue, 20 Mar 2001 00:00:26 -0800
- Envelope-to: multi6-data@psg.com
- User-Agent: Mutt/1.2.5i
This draft can also be found at:
http://www.layer8.net/~ben/drafts/draft-black-multi6-requirements-00.txt
Flame on.
Ben
Vijay
Joe
--
Network Working Group B. Black
Internet-Draft Layer8 Networks
Expires: August 2, 2001 V. Gill
J. Abley
Metromedia Fiber Network Inc.
February 2001
Requirements for IP Multihoming Architectures
draft-multi6-multihoming-requirements-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 2, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Multihoming is an essential component of service for autonomous
systems connected to the Internet. The existing multihoming
architecture is based on CIDR [1], which is predicated upon a
hierarchy of service providers.
However, it appears that this hierarchy is being supplanted by a
dense mesh of interconnections [5]. Additionally, there has been an
enormous growth in the number of multihomed organizations. For
purposes of redundancy and load sharing, the multihomed customer
blocks, which are almost always a longer prefix from the provider
Black, et. al. Expires August 2, 2001 [Page 1]
Internet-Draft IP Multihoming Requirements February 2001
aggregate, are announced, along with the larger aggregate by the
provider. This results in rapidly increasing size of the global
routing table. This explosion places significant stress on both the
routing protocols and the routing hardware.
Migration to IPv6 with its greatly enlarged address space is likely
to exacerbate the weaknesses in the existing system.
This document outlines a set of requirements for new multihoming
architectures to address weaknesses in the current, CIDR-based
infrastructure.
Black, et. al. Expires August 2, 2001 [Page 2]
Internet-Draft IP Multihoming Requirements February 2001
1. Introduction
Multihoming is an essential component of service for autonomous
systems connected to the Internet. The existing multihoming
architecture is based on CIDR [1], which is predicated upon a
hierarchy of service providers.
However, it appears that this hierarchy is being supplanted by a
dense mesh of interconnections [5]. Additionally, there has been an
enormous growth in the number of multihomed organizations. For
purposes of redundancy and load sharing, the multihomed customer
blocks, which are almost always a longer prefix from the provider
aggregate, are announced, along with the larger aggregate by the
provider. This results in rapidly increasing size of the global
routing table. This explosion places significant stress on both the
routing protocols and the routing hardware.
Migration to IPv6 with its greatly enlarged address space is likely
to exacerbate the weaknesses in the existing system.
Black, et. al. Expires August 2, 2001 [Page 3]
Internet-Draft IP Multihoming Requirements February 2001
2. 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 [2].
Black, et. al. Expires August 2, 2001 [Page 4]
Internet-Draft IP Multihoming Requirements February 2001
3. Multihoming Requirements
Multihoming is the connection of one autonomous system to multiple,
other autonomous systems. This is done for reasons of service
redundancy and reliability, and also for load-sharing.
3.1 Redundancy
By obtaining transit through more than one provider, a network can
insulate itself from certain failure modes of one or more providers,
as well as failures within layer 1 and layer 2 infrastructure.
Specific failure modes which must be protected against by any
solution for site multihoming in IP networks include:
o Physical link failure, such as a fiber cut or router failure,
o Logical link failure, such as a misbehaving router interface,
o Routing protocol failure, such as a BGP peer reset,
o Service provider failure, such as a backbone-wide IGP failure, and
o Exchange failure, such as a BGP reset on an inter-provider
peering.
Additionally, during failure events described above, multihoming
solutions must provide re-routing transparency for applications;
i.e. exchange of data between devices on the multi-homed network and
devices elsewhere on the Internet may proceed with no greater
interruption than transient packet loss during the re-routing event.
3.2 Load Sharing
Load sharing is distributing traffic across multiple links. Reasons
for load sharing include but are not limited to:
o Performance,
o Cost, and
o Availability of Infrastructure.
3.3 Performance
One of the reasons for multihoming with two providers is poor
connectivity between them. For example, customer C is buying transit
from ISP A, and there is long term congestion between ISP A and ISP
B. To improve connectivity to ISP B, customer C buys transit from
Black, et. al. Expires August 2, 2001 [Page 5]
Internet-Draft IP Multihoming Requirements February 2001
ISB B, thus bypassing the congestion and improving the performance
between C and ISP A.
Some operators have requirements to provide different grades of
connectivity to customers based on network reach, and achieve this
objective by grouping customers of similar service grades together,
and advertising their networks over separate transit circuits. The
result is multihoming for the purpose of transit capacity
segregation.
3.4 Cost
A provider may choose to multihome for financial reasons. For
example, customer C homed to ISP A may wish to shift traffic of a
certain class or application, NNTP, for example, to ISP B because
ISP B charges less for traffic. Any future multihoming proposals
must provide support for multihoming for financial reasons.
3.5 Availability of Infrastructure
Sometimes it is not possible to increase transit capacity to a
single provider, because that provider does not have sufficient
spare capacity to sell. In this case a solution is to acquire
additional transit capacity through a different provider. This
scenario is common in bandwidth-starved stubs of the network where,
for example, transit demand outpaces under-sea cable deployment.
3.6 Simplicity and Scalability
As any proposed multihoming solution must be deployed in real
networks with real customers, simplicity is paramount. The current
multihoming solution, despite its drawbacks, is quite
straightforward to deploy and maintain.
Unlike the current solution, however, new solutions must provide for
scaling of the number of multihomed sites many orders of magnitude
larger than are currently deployed. The limitations for scalability
with the existing solution and current protocols are outlined in
Section 4.
Black, et. al. Expires August 2, 2001 [Page 6]
Internet-Draft IP Multihoming Requirements February 2001
4. Overview of the Current Architecture
4.1 Motivations for CIDR-Based Site Multihoming
The CIDR-based solution currently deployed meets most of the
requirements defined in Section 3, but also provides the following
features:
o Conceptually simple
o Fine-grained policy control for multihomed sites
4.2 Drawbacks of CIDR-Based Site Multihoming
When a site multi-homes, one or more additional prefixes are
introduced into the global BGP table. If the site uses
provider-aggregatable addresses, then upstreams may need to
advertise both the aggregate and the more specific route, resulting
in super-linear growth of the default-free zone.
Concern over prefix-table growth in the default-free zone is leading
at least one large provider to filter advertisements received from
peers on the basis of allocation boundaries, such that long-prefix
provider-aggregatable prefixes are denied transit across that
provider's network. If this approach becomes more widespread, the
ability to multi-home effectively will become restricted to those
networks who have sufficient addressing requirements to justify a
provider-independent allocation.
Furthermore, increasing numbers of multihomed sites accelerates the
growth in the number of distinct paths for a given prefix in the
default-free zone. This causes a significant increase in the
convergence time for BGP after network changes. This issue is
discussed in great detail in [5].
Although conceptually simple, this approach does not lend itself
well to troubleshooting of inter-AS network pathologies. The
opacity of policy interaction between ASes in the network can hide
numerous, unpredictable path selection behaviors.
Black, et. al. Expires August 2, 2001 [Page 7]
Internet-Draft IP Multihoming Requirements February 2001
References
[1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[4] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format", RFC 2374, July 1998.
[5] Huston, G., "Analyzing the Internet's BGP Routing Table",
January 2001.
Authors' Addresses
Benjamin Black
Layer8 Networks
EMail: ben@layer8.net
Vijay Gill
Metromedia Fiber Network Inc.
8075 Leesburg Pike
Suite 300
Vienna, VA 22182
US
Phone: +1 410 262 0660
EMail: vgill@mfnx.net
Joe Abley
Metromedia Fiber Network Inc.
2204 Pembroke Court
Burlington, ON L7P 3X8
Canada
Phone: +1 905 319 9064
EMail: jabley@mfnx.net
Black, et. al. Expires August 2, 2001 [Page 8]
Internet-Draft IP Multihoming Requirements February 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Black, et. al. Expires August 2, 2001 [Page 9]