Hi Joe, I should have used Overlay Controller Schemes instead of OCP, all current overlay solution do have some "signalling" mechanisms to setup and tear down the tunnels, a bunch of protocols. Probably you could make extensions to SIP as well and have that as an Overlay Controller Scheme (OCS), that would be on standards tracks.
You are right about RTCP, it is not in the data path/inside the stream - it is between endpoints and de facto in the data path, otherwise it would be useless collecting statistics for the codec to detect transmissions faults and jitter etc. Why not do the similar for NVO3, design OTCP so that the OAM is active on all ECMP paths between two VTEPs though there is only one active end system stream between the VTEPs. And the OAM packets do not need to carry the header&payload of whatever encapsulation protocol is used, decouple that so you can use whatever encapsulation protocol fit your needs. Have mandatory TLVs here (OAM, traceroute, ping etc) and have optional TLVs so if there is some OCS that have problems to send their own extension over the signalling path between VTEPs then that OCS can use this protocol to send state or whatever information is needed between the VTEPs - without introducing new hardware encoding offloading tweaks for everyone or breaking them by some new strange information. Regards, Patrick On Wed, Aug 10, 2016 at 12:05 AM, Joe Touch <[email protected]> wrote: > Hi, Patrick, > > > On 8/9/2016 1:02 PM, Patrick Frejborg wrote: >> Whoa! >> Will indeed have a look on URL you posted, thanks! >> >> RTP is perhaps the wrong reference, I should have referred the >> different overlay tunnels as NVO3 "codecs", the payload inside the >> RTP, the audio/video profile identifier. Then these overlay tunnel >> protocols can evolve, as the DSPs evolved/evolving in the >> communication systems. > Sure, but then: > > SIP == x-bone-api > i.e., it's the way the user indicates what to deploy > > RTP = x-bone-ctl > i.e., the way the resources are discovered and components configured > > You don't need a protocol to specifically deploy just tunnels; they're > just one part of the overall picture (which includes addressing, > routing, etc.). > ... >> The difference between SIP messages and RTCP is that SIP messages >> between a SIP UA and a SIP proxy/registrar > Yes, as per above, SIP is closer to x-bone-api (I can't speak for the > others). > >> do take a different path in >> the network what the RTP messages are using - the SIP messages are off >> the data path (the signalling path) and the RTCP messages are on the >> data path. >> > > RTCP are not in the data path; they're between data endpoints. There's > no requirement that they traverse the same path as the codec'd data. > > Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
