One document matched: draft-ietf-msdp-server-00.txt
Group Specific MSDP Peering
<draft-ietf-msdp-server-00.txt>
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.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), ftp.ietf.org (US East
Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract
The MSDP protocol is based on the assumption that there is one or a
few RPs in the PIM domain. In the presence of potential numerous RPs
in the context of multicast security, Source Active messages will be
flooded unnecessarily to the RPs that are not responsible for the
concerning group in the messages.
This memo introduces MSDP server and proposes all RPs to set up
internal group specific MSDP peering with the MSDP server. Each
Source Active message will be forwarded between the MSDP server and
the elected RP for the concerning groups in the message.
The concept of group specific peering can also apply to MSDP routers
between a central multicast domain and an edge domain.
Y. Li Expires 5 December 1999 [Page i]
Internet Draft Group Specific MSDP Peering 4 June 1999
1. Introduction
The MSDP specification ([2]) implies a router supporting MSDP is a
RP. In the presence of multiple RPs in a PIM-SM domain, each
representing a distinct range of groups, multiple MSDP peering pairs
have to be set up internally between these RPs. As a result, Source
Active (SA) messages will be unnecessarily forwarded to each RP which
is not the elected RP for the group it is concerned with.
On the other hand, recent research in multicast security indicates
a regional security broker can be a RP of a PIM domain. Hence the
number of RPs in a PIM domain potentially can grow beyond what the
PIM-SM specification ([1]) assumes. As a result, the overhead in
unnecessarily forwarding SA messages internally in the PIM domain
is significant.
This document is to minimize forwarding MSDP messages internally by
introducing MSDP server. The MSDP server is a candidate RP who
represents all groups (224.0.0.0/4). It has the lowest priority so
that it has the least chance to be elected as a RP. MSDP servers
peer with each other externally. In a PIM domain, each individual RP
obtain as a client an internal group specific peering session from
local MSDP server. The MSDP server will forward to the RP only those
SA messages with the concerning group in the RP's group scope.
When a source originates multicast data, the RP responsible for the
group in concern generates a SA message and sends it to the local
MSDP server. The SA message will then be flooded server-by-server
over the MSDP backbone. When receiving the SA message, each MSDP
server will determine the local RP for the particular group and
forward the message to the particular RP. This particular RP will
determine if it has (*,G) state and, if so, will trigger (S,G) join
towards the source.
This approach will essentially minimize the MSDP traffic internally
in PIM-SM domains, simplify autoconfiguration of internal MSDP
peering, and facilitate configuration of MSDP policies.
The concept of group specific MSDP peering can apply to MSDP routers
between a central multicast domain and an edge domain. This can be
done by MSDP policy. In this manner, edge domains will be protected
from receiving excessive MSDP traffic.
Y. Li Expires 5 December 1999 [Page 1]
Internet Draft Group Specific MSDP Peering 4 June 1999
2. Terminology
MSDP Server
A MSDP server is a default candidate RP (C-RP), which is
configured for all groups, i.e., 224.0.0.0/4. It has the lowest
priority value so that, if there is another C-RP for more
specific group range(s), this other C-RP will take precedence
over the MSDP server for the election of the RP for a particular
group.
External MSDP Peering
The peering between two MSDP servers or between a MSDP server
and a RP in another PIM domain (provided there is no MSDP server
in this other domain). Typically this is done by configuration.
Internal MSDP Peering
The peering between a RP and the local MSDP server. The RP
should actively request a MSDP peering from the MSDP server.
The internal peering is group specific; the MSDP server only
forwards those SA messages with the concerning group in the
RP's group scope.
RP's Group Scope
A RP's group scope is the range of group addresses which the RP
indicates in its C-RP Advertisement messages. The bootstrap
router may modify the group range.
Y. Li Expires 5 December 1999 [Page 2]
Internet Draft Group Specific MSDP Peering 4 June 1999
3. MSDP-Bit in C-RP Advertisement and Bootstrap Message
We define a S-bit, or MSDP-bit, in both C-RP Advertisement and
Bootstrap messages to indicate the MSDP capability of the C-RP.
3.1 Extended Candidate-RP-Advertisement
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |S| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Cnt | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S-bit If it is set, the C-RP has external MSDP peerings.
If it is cleared, the C-RP has no external peering.
3.2 Extended Bootstrap Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask len | BSR-priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-BSR-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-1 | Frag RP-Cnt-1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Y. Li Expires 5 December 1999 [Page 3]
Internet Draft Group Specific MSDP Peering 4 June 1999
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Group Address-n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP-Count-n | Frag RP-Cnt-n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP1-Holdtime | RP1-Priority |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP2-Holdtime | RP2-Priority |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address-m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm-Holdtime | RPm-Priority |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S-bit If the S-bit in a RP fragment is set, the particular C-RP
has external MSDP peerings. Otherwise, the RP has no
external peering.
4. RP Considerations
When it learns from the Bootstrap message that it itself is an
elected RP for certain range of groups, a C-RP should actively start
an internal MSDP peering session with the local MSDP server. However,
if the C-RP itself is a MSDP server, there is no need for the above
internal peering.
The C-RP learns the MSDP server by looking up the S-bit in the
Bootstrap message. However, if two or more MSDP sevrers are learned,
the one with the highest priority should be taken. In case of a tie,
the hash function should be run between them and the one with the
highest hash value should be taken.
Y. Li Expires 5 December 1999 [Page 4]
Internet Draft Group Specific MSDP Peering 4 June 1999
When the RP learns a new source from PIM Register message, it
constructs an SA message and sends to the local MSDP server.
When the RP receives a SA-request from the MSDP server, it should
return to the server with a set of SA entries, in a SA-Response
message, for all active sources in the PIM domain.
When the RP receives a PIM Join message for a group, creates (*,G)
state and wants to know all active sources for group G, it should
send the MSDP server an SA-Request message for the group.
5. MSDP Server Considerations
A MSDP server indicates its MSDP external capability by sending
Candidate RP Advertisement message to the Bootstrap router with the
S-bit set.
If the policy allow, the MSDP server should automatically accept MSDP
internal peering session from each elected RP.
When it receives a SA message from a RP in the same PIM domain, the
MSDP server should forward it to all external MSDP peers. However,
no copy of the SA message should be forwarded to the other RPs in the
PIM domain.
When it receives a SA message from an external MSDP peer, the server
forwards it to external MSDP peers in peer-RPF flooding fashion. It
also determines the elected RP for the group in concern, and forwards
a copy of the SA message to the RP.
When a MSDP server comes up from reboot, it may send a SA-request
message to certain external MSDP peer, and to all elected RPs in the
same PIM domains.
The MSDP server processes SA-request message in same way as in the
MSDP protocol ([2]).
6. Acknowledgement
The multicast development group in Nortel Networks has provided
valuable comments. Special thanks to Billy Ng for his comments and
suggestions.
Y. Li Expires 5 December 1999 [Page 5]
Internet Draft Group Specific MSDP Peering 4 June 1999
References
[1] D. Estrin et al, "Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998.
[2] D. Farinacci et al, Multicast Source Discovery Protocol (MSDP),
Internet Draft, work in progress, June 1998.
Authors' Addresses
Yunzhou Li
Nortel Networks
BL60-304
600 Technology Park Drive
Billerica, MA 01821
Phone: 1-978-288-1130
Fax: 1-978-670-8760
E-mail: yunli@NortelNetworks.COM
Y. Li Expires 5 December 1999 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 21:52:28 |