نمایش نتایج: از شماره 1 تا 1 , از مجموع 1

موضوع: mbgp

  1. #1
    کاربر عادی shadow آواتار ها
    تاریخ عضویت
    Aug 2007
    محل سکونت
    نوشته ها
    تشکرها / پسندها

    پیش فرض mbgp

    Interdomain Multicast Routing:
    Use of MGBP to provide Scaleable, Policy Based
    Interdomain Multicast Exchange

    Last updated June 3, 1998


    Initial deployment of multicast throughout the Internet
    has been based on the use of the Distance Vector Multicast
    Routing Protocol routing independently from the underlying
    unicast routing protocols of the Internet. This routing
    topology is flat, all global participants exchanging multicast
    based on DVMRP are sharing a single DVMRP routing table.
    While this approach was extremely useful in demonstrating
    the viability of multicast over the Internet, it retains all
    the inherent disadvantageous of running a distance vector
    protocol over the Internet
    - poor scalability (currently under strain at ~6000 routes)
    - poor convergence
    - limited policy control (resulting in limited acceptance
    in production ISP environments)
    - waste of bandwidth based on periodic routing updates in
    both directions of a link (i.e. poison-reverse).

    In addition, much of the existing multicast backbone (MBone)
    utilizes tunnels among non-production routing platforms and
    is administered outside of the operational network engineering
    and ops support groups (eg via R&D, sysadmin, etc).

    Current Motivation for Internet Multicast:

    Despite these limitations, the interest in multicast
    continues to rise. The use of streaming multimedia and
    multi-destination apps has increased significantly in the
    Internet and has pushed the demand for multicast in two ways:

    1) in order to reduce bandwidth consumption from a network
    design perspective
    2) in order to provide effective multipoint distribution from
    an applications perspective
    3) in order to provide effective scalable distribution from
    large-scale applicastions perspective.

    Move toward Production Multicast:

    Now more and more networks are running production multicast
    co-resident on their production unicast routing infrastructure
    and utilizing the underlying unicast routing protocols for
    multicast forwarding decisions.
    One stark exception to this is at the interdomain routing space.
    In order to address the demand for scalable, production multicast
    most ISPs have stated that they require an effective interdomain
    routing solution. This has two parts:
    1) a multicast EGP which provides scalability and policy control
    analogous to BGP. This will be discussed here.
    2) a method of establishing multicast forwarding trees across
    interdomain space, and which avoids extensive dependency
    on third parties (eg other ISPs). Possible solutions to
    this component being discussed by the IETF include BGMP/
    MASC. This is not covered in this draft.

    Multicast BGP:

    Multicast Border Gateway Protocol (MBGP) offers a method
    for providers to distinguish which prefixes they will use
    for performing multicast reverse path forwarding (RPF)checks.
    Recall the RPF check is fundamental in establishing
    multicast forwarding trees and moving multicast content
    successfully from source to receiver(s).
    MBGP is based on RFC 2283, Multiprotocol Extensions for BGP-4.
    This brings along all of the administrative machinery that
    providers (and customers for that matter) like in their
    inter-domain routing environment. Examples include all of the AS
    machinery, and the tools to operate on it (e.g., route maps).
    Therefore, by using MBGP, any network utilizing internal or
    external BGP can apply the multiple policy control knobs
    familiar in BGP to specify routing (and therefore forwarding)
    policy for multicast.
    Two path attributes, MP_REACH_NLRI and MP_UNREACH_NLRI,
    are introduced to yield BGP4+ as described in Internet Draft
    MBGP is a simple way to carry two sets of routes. One set for
    unicast routing and one set for multicast routing. The routes
    associated with multicast routing are used by the multicast
    routing protocols to build data distribution trees.


    o An internet can support non-congruent unicast and multicast
    o An internet, when the unicast and multicast topologies are
    congruent, can support differing policies.


    o Multiple sets of routes for the same prefixes are carried in
    BGP and stored in routers.

    Deployment challenges for MBGP:

    As will be the case with many newly emerging internetwork
    protocols, one of the deployment challenges will be to
    gracefully migrate the new protocol onto an existing
    production routing infrastructure. Unlike HTTP/Web services
    which could be deployed and propagated without alteration
    of the routing infrastructure, multicast and in particular,
    MBGP require that production BGP peering routers get upgraded
    to new images supporting MBGP, and that routing policy be
    changed and reflected by updating router configs. This is
    a fairly large risk for most ISPs for several reasons:

    - most of the routers to run MBGP are critical production
    routers, usually already under heavy unicast load
    - images supporting MBGP do not have significant uptime
    compared to mainline images and as such have a higher
    probability of containing bugs of varying severity
    - subtle configurations issues exist regarding how to make
    MBGP work (and accurately reflect policy)
    - interprovider multicast policy in general is poorly
    understood due to limited experience.

    These issues must be resolved at least to the degree which
    analogous unicast issues have been, such that providers can
    confidently deploy MBGP and multicast as a production service.

    Multicast over current NAPs:

    Multicast BGP peering currently across many popular
    NAPs is prohibited by the existing physical architecture
    of the NAP. Some NAP switching infrastructures treat multicast
    as broadcast, defeating the purpose of the switch and can
    creating unwanted redistribution and load on the switch,
    and switch<->switch or switch<->router links.

    MBGP Deployment:

    Due to the issues stated, an MBGP deployment effort was
    initiated by Cisco, several ISPs, and NAP operators
    and focuses on these objectives:
    - demonstrate stability and configurability in mbgp code
    - develop multicast exchange points which bootstrap deployment
    of multicast across exchanges without impacting existing
    unicast traffic.
    - provide participants with a method of gaining operational
    experience with MBGP and policy definition prior to full
    scale production deployment, and to feed this information to
    multicast operators and multicast-related IETF working groups.

    Current MBGP Deployment Status:

    Initial MBGP deployment involves several NAPs including
    exchanges at Ames Research Center, Palo Alto, Pensauken,
    and Stockholm.
    At these NAPs, dedicated fddi concentrators are set-up to
    provide a non-switched media across which participating
    ISPs can peer via multicast nlri. Only multicast is
    forwarded across these multicast exchanges, unicast forwarding
    still occurs via the existing switched NAP. Since unicast and
    multicast peering paths are non-congruent, mbgp is used
    to specify different routing information bases (RIBs) for
    multicast and unicast forwarding.

    Participating ISPs provide a separate fddi interface to
    attach to the multicast exchange and run the MBGP code on
    their peering routers.
    Initial participating providers include various commercial
    and federal ISPs, such as NASA Ames Research Center which
    participates as both a peering ISP (the NASA Research and
    Education Network is currently running a full internal
    mbgp mesh), and as an operator of one of the initial
    multicast exchange points utilizing mbgp.

    Cisco Systems provided the first mbgp code available
    for deployment. Configuration examples for participating
    in mbgp peerng are avaiable at:

    Multicast Forwarding Protocols being used in deployment effort:

    A variety of internal multicast forwarding protocols are
    run by participating ISPs including PIM-SM, PIM-DM, and

    PIM-SM (or PIM Sparse-Dense-Mode, which is recommended):

    For those ISPs running PIM-SM, their internal RP must be
    located at the border router, sitting on the multicast
    exchange running PIM-DM. This way content can be flooded among RPs
    and forwarded to the receivers within their respective domains.


    For ISP's running PIM-DM internally, they simply need to
    initiate peering at one of the multicast friendly exchange


    For ISPs running DVMRP, Cisco's MBGP implementation supports
    two way redistribution of routes between MBGP and DVMRP, such
    that the ISP can MBGP peer with its neighbors at the exchange,
    and service internal sites running DVMRP.

    For ISPs who have positioned their RP at one NAP, and
    would like to communicate with ISPs who's RP is at a separate
    NAP, it is necessary to get source information among the NAPs.
    Initially this is being done via a temporary short-lived backbone
    of GRE tunnels (transit provided by various participating ISPs)
    running PIM-DM and and an iMBGP mesh using AS10888
    (provided by NASA Ames Research Center).
    These tunnels (and AS10888) route between dedicated MBGP routers
    sitting at each participating NAP. ISPs at each multicast NAP can
    then elect to peer with these routers in AS10888 and obtain multicast
    connectivity with other Sparse-mode ISPs peering with AS10888.

    It is important to note that AS10888 is only intended to facilitate
    initial deployment of multicast while ISPs establish early
    peering. AS10888 can be disassembled when one of three things
    1) Participating ISPs provide DM transit between NAPs as part of
    their peering agreement. (Only one DM path is necessary between
    each NAP, but multiple paths could be provided).
    2) Participating ISPs provide BGMP transit between NAPs. This
    proposal is still under development within the IETF.
    3) A protocol is developed which can distribute information
    about sources to all RPs. One such protocol under development
    is Multicast Source Distribution Protocol (MSDP).


    MSDP is designed to provide a method of distributing
    information about active sources within each multicast
    routing domain. Top level RPs for each domain pass
    source active information to each other, rather than
    flooding content, in order to determine the presence
    of active sources within the Internet. Once this
    information is available, it can be used by receivers
    to join the source-based trees across domain boundaries
    for a given source.
    Deployment of MSDP will rescind the need to flood content
    among the participating NAPs, and will allow for
    disassembly of the AS10888 backbone.


    Multicast BGP (MBGP) provides for scalable, policy-
    based interdomain routing which can be used to support
    non-congruent unicast and multicast forwarding paths.
    MBGP is necessary to establish scalable, production multicast
    services over the Internet. However, the integration of
    MBGP and production multicast into an existing production
    unicast infrastructure is problematic. A deployment
    effort is underway to help facilitate this integration
    and to move multicast toward a ubiquitous Internet

  2. # ADS
    Circuit advertisement
    تاریخ عضویت
    محل سکونت
    Advertising world
    نوشته ها

اطلاعات موضوع

کاربرانی که در حال مشاهده این موضوع هستند

در حال حاضر 1 کاربر در حال مشاهده این موضوع است. (0 کاربران و 1 مهمان ها)

علاقه مندی ها (Bookmarks)

علاقه مندی ها (Bookmarks)

مجوز های ارسال و ویرایش

  • شما نمیتوانید موضوع جدیدی ارسال کنید
  • شما امکان ارسال پاسخ را ندارید
  • شما نمیتوانید فایل پیوست کنید.
  • شما نمیتوانید پست های خود را ویرایش کنید