draft-ietf-mpls-multicast-07.txt | draft-ietf-mpls-multicast-08.txt | |||
---|---|---|---|---|
Network Working Group D. Ooms, B. Sales | Network Working Group D. Ooms, B. Sales | |||
Internet Draft Alcatel | Internet Draft Alcatel | |||
Expiration Date: July 2002 W. Livens | Expiration Date: October 2002 W. Livens | |||
Colt Telecom | Colt Telecom | |||
A. Acharya | A. Acharya | |||
IBM | IBM | |||
F. Griffoul | F. Griffoul | |||
Ulticom | Ulticom | |||
F. Ansari | F. Ansari | |||
Bell Labs | Bell Labs | |||
January 2002 | April 2002 | |||
Framework for IP Multicast in MPLS | Framework for IP Multicast in MPLS | |||
draft-ietf-mpls-multicast-07.txt | draft-ietf-mpls-multicast-08.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 22, line 25 | skipping to change at page 22, line 25 | |||
can be maintained but the label advertisement is duplicated in space. | can be maintained but the label advertisement is duplicated in space. | |||
Since LSPs are only rewarding if they have a long lifetime and since | Since LSPs are only rewarding if they have a long lifetime and since | |||
the number of LSRs on a shared link is limited the second approach | the number of LSRs on a shared link is limited the second approach | |||
seems advantageous. | seems advantageous. | |||
Another issue with multicast in multi-access networks is whether to | Another issue with multicast in multi-access networks is whether to | |||
use upstream or downstream label assignment. For multicast traffic, | use upstream or downstream label assignment. For multicast traffic, | |||
upstream label allocation is simpler since there can be only one | upstream label allocation is simpler since there can be only one | |||
upstream node per link that belongs to a multicast tree. This | upstream node per link that belongs to a multicast tree. This | |||
(upstream) node can assign a label without any contention. With | (upstream) node can assign a unique label for the FEC. With | |||
downstream allocation, there may be multiple downstream nodes for a | downstream allocation, there may be multiple downstream nodes for a | |||
given tree on a multi-access link; each node may propose a label | given tree on a multi-access link; each node may propose a different | |||
assignment leading to contention and a contention resolution scheme | label assignment for a FEC which would require some resolution | |||
is required to chose one of them as the label allocator. | process in order to come of with a single label per multicast FEC on | |||
the link. | ||||
Once a label has been assigned, it is possible that the label | Once a label has been assigned, it is possible that the label | |||
assigner leaves the tree. With downstream label assignment, this | assigner leaves the tree. With downstream label assignment, this | |||
could happen when the label allocator leaves the group. With | could happen when the label allocator leaves the group. With | |||
upstream assignment this could happen when the upstream LSR changes | upstream assignment this could happen when the upstream LSR changes | |||
due to a unicast topology change. | due to a unicast topology change. | |||
10. More issues | 10. More issues | |||
10.1. TTL field | 10.1. TTL field | |||
skipping to change at page 25, line 29 | skipping to change at page 25, line 29 | |||
a) Easier label allocation in multi-access networks (see section 9). | a) Easier label allocation in multi-access networks (see section 9). | |||
b) The same label can be kept when the downstream LSR (which would | b) The same label can be kept when the downstream LSR (which would | |||
have been the label allocator in downstream mode in a multi-access | have been the label allocator in downstream mode in a multi-access | |||
network) leaves the group (see section 9). | network) leaves the group (see section 9). | |||
c) The upstream and implicit distribution mode allow a faster LSP | c) The upstream and implicit distribution mode allow a faster LSP | |||
setup when the LSP is traffic triggered. | setup when the LSP is traffic triggered. | |||
Whether to use upstream or downstream label distribution is outside | ||||
the scope of this framework. The relative complexity between the | ||||
necessary protocol extensions and the resolution mechanism needed, | ||||
as well as the relative operational complexity, will influence which | ||||
way to go. | ||||
10.5. Explicit vs. Implicit Label Distribution | 10.5. Explicit vs. Implicit Label Distribution | |||
Beside the explicit distribution modes (which use a signaling | Beside the explicit distribution modes (which use a signaling | |||
protocol), [ACHA] proposes an implicit label distribution method by | protocol), [ACHA] proposes an implicit label distribution method by | |||
using unknown labels. This method has all the advantages of the | using unknown labels. This method has all the advantages of the | |||
upstream label allocation method and is probably the fastest label | upstream label allocation method and is probably the fastest label | |||
advertisement method for traffic triggered LSPs. | advertisement method for traffic triggered LSPs. | |||
Implicit label distribution is not applicable if the FEC-to-label | Implicit label distribution is not applicable if the FEC-to-label | |||
binding has been advertised prior to traffic arrival, e.g. explicit | binding has been advertised prior to traffic arrival, e.g. explicit | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |