The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt
> I guess, it is not the task of the LSP to de-multiplex the received > data at any particular leaf node of the mp2mp-LSP, although this needs > to be done, too, however by some entity elsewhere. I Just to make a clarification. A true leaf of a MP2MP LSP does not need to do any de-multiplexing. Packets are received on one label, and are send using one label. > think there are two alternatives wrt the mp2mp-LSP: > (1) n p2mp-LSPs > (2) n mp2p-LSPs. > > Whereas mp2mp-LSP is a third and different solution and should be > handled accordingly. > It is NOT a special p2mp-LSP, but I am afraid this is the view of the > designers - for 2 reasons: It is a MP2MP LSP from the point of view of the leafs, there is an upstream path to send to and a downstream path to receive from. If you look at the internals, it is a P2MP LSP from the root to all the leafs. There is a P2P LSP from the leaf to the next upstream LSR until you reach the root. While MPLS packets are forwarded upstream, they are allowed to go down the P2MP LSP if there are receivers. Thx, Ice. > 1: because all is designed in the light of upstream/downstream > 2: it is not worth a separate draft, instead is like an appendix to > section 2 which deals with the p2mp-LSP. > > Heiner > > > In einer eMail vom 03.03.2006 15:05:03 Westeuropäische Normalzeit > schreibt John.Rutemiller@marconi.com: >> >> A construct that has not been mentioned, but is useful in this >> discussion is mp2p. >> >> Based on Neil's definition, mp2p is not a connection. This makes >> sense when you think about it. At the reciever, additional >> information is needed to identify the sender of each packet in order >> to recover the individual streams. So, mp2p is a multiplexing action >> which requires demultiplexing at the receiver. >> >> This is useful to keep in mind when talking about mp2mp. A mp2mp >> construct is actually a combination of p2mp and mp2p. >> >> From the point of view of the sender, mp2mp looks like a p2mp >> connection. In the MPLS world, any packet entering the network will >> take a fixed and known path to the recievers. Looking at only this >> behavior, mp2mp looks like a connection. >> >> From the point of view of the receiver, mp2mp looks like mp2p. The >> receiver requires additional information in order to identify and >> recover the different traffic streams. >> >> >> John >> >> >> >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: Friday, March 03, 2006 7:22 AM >> To: HeinerHummel@aol.com; mpls@lists.ietf.org >> Subject: RE: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt >> >> An observation. There is no such construct as a mp2mp >> *connection*.....one can have any-any in a cl-ps mode network >> (precisely because there are no connections) but it is NOT possible >> to have mp2mp connections in either a co-ps or co-cs mode network. >> This can be proved by an appeal to (Shannon) information >> theory.....but it would require a very lengthy explanation, >> especially wrt how labelling works (its not as simple as some folks >> might assume). >> >> However, let me simply state here what the bottom-line >> conclusions/rules are: >> A connection must: >> - only have a single source >> - only have connectivity of 1 >> >> ....so only p2p and p2mp connection constructions are allowed. >> >> Further, and consequential from the above: >> - ordering of traffic units is preserved in a connection >> - once created there is no routing choice available in a connection >> >> A trail is 'the source to a specific-sink' relationship in these >> connection constructs. >> regards, Neil >>> -----Original Message----- >>> From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] >>> Sent: 02 March 2006 10:59 >>> To: mpls@lists.ietf.org >>> Subject: Re: [mpls] I-D ACTION:draft-ietf-mpls-ldp-p2mp-00.txt >>> >>> >>> Some critical notes wrt mp2mp LSP: >>> >>> The terms upstream and downstream relate to the terms ingress and >>> egress, but not to root (and three times not to root while keeping >>> open whether the root is an ingress(+egress) at all). >>> >>> The mp2mp LSP is supposed to be a mesh-less delivery channel which >>> interconnects a specific set of leaf nodes such that at any junction >>> traffic is forwarded to all other directions except the one from >>> where it is received. This is my understanding about the mp2mp >>> stream direction. The presented design with its upstreams and >>> downstreams all over the place is fairly a sign of ossification, >>> isn't it ? >>> >>> Heiner Hummel >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|