Hi Reinaldo et al.,
like to inform you that an initial package proposal is now available:
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0801_Seo/AVD-3277.zip
AVD-3277 Proposed new Draft ITU-T Rec. H.248.IPR ? IP Router Package
Comments would be appreciated!
Best regards,
Albrecht
"Reinaldo Penno"
<rpenno@juniper. To: <[email protected]>
net> cc: [email protected]
Subject: RE: H.248 IP Router Package; Re: [Megaco] Question on Interface Routing ...
11.03.2007 21:33
Okay,
I guess I will wait for the document and some examples so we can continue
our discussion.
Thanks,
Reinaldo
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> Sent: Sunday, March 11, 2007 9:14 AM
> To: Reinaldo Penno
> Cc: [email protected]
> Subject: RE: H.248 IP Router Package; Re: [Megaco] Question
> on Interface Routing ...
>
> Reinaldo,
>
> 1)
> starting point is the H.248.1 connection and context model,
> don't be so minded from an service/edge/core router perspective.
> There are two terminations types, PHY and EPH terminations.
> Relevant here is the principle how H.248 Streams/Terminations
> got there network address (or connection endpoint address).
> H.248 Contexts with two IP terminations is nothing new, - the
> Ia/1 profile is not the first application.
>
> The general context for packet-switched networks for 2PTY
> communication is EPH-to-EPH. We got applications already
> before TISPAN R1 in mobile (see 3GPP R4) and fixed networks.
> I cannot see nothing new with IP-to-IP Contexts. This was
> already part of the H.248.1 V1 design since 6, 7 years.
> (Guess this is one majore difference to MGCP, which primarily
> supports only PHY-to-IP connection models.)
>
> 2)
> Ia TerminationID naming scheme and term "interface":
> I may guess that this term might be confusing when having
> only logical/physical IP interfaces in mind.
> But the ES 283 018 term is more general, could be a "generic
> interface" or even just a non-IP interface, like a layer 2 interface.
> Please note that this TerminationID field is used to
> "emulate" the H.248.41 functionality ("IP realm indication"),
> whereas the IP connection endpoint identification is given by
> LD/RD IP address information, IP SA/SP used for egress
> traffic and the TermID.
> [So, the ES 283 018 TermID field "interface" is typically
> related to an "IP address range", but not a single address.]
>
>
> Don't think that the H.248 concept is broken with the Ia
> Profile, it's rather vice versa the the H.248 connection
> model did consider from the initial design EPH-to-EPH connections.
>
> Perhaps another aspect is that
> the B2BIH function is related to session-dependent control
> (like in TISPAN RACS, wherease the IPR is basically
> session-independent (e.g. like for RACS).
>
> -Albrecht
>
>
>
>
>
>
>
>
> "Reinaldo Penno"
>
>
> <rpenno@juniper. To:
> <[email protected]>
>
> net> cc:
> [email protected]
>
> Subject: RE:
> H.248 IP Router Package; Re: [Megaco] Question on Interface
> Routing ...
> 11.03.2007 11:42
>
>
>
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]
> > Sent: Sunday, March 11, 2007 2:00 AM
> > To: Reinaldo Penno
> > Cc: [email protected]
> > Subject: RE: H.248 IP Router Package; Re: [Megaco] Question on
> > Interface Routing ...
> >
> >
> > Reinaldo,
> >
> > like to start with your last comments.
> >
> > We should recall that an H.248 IP-to-IP MG, - with an H.248 Context
> > with two H.248 IP Terminations (T1, T2; with Streams
> > S1) -, is firstly behaving as an Back-to-Back IP Host
> (B2BIH), and not
> > as an IP Router (IPR).
> >
>
> Well, I think this where the disconnect is. Originally a MGW
> was like a glotified TDM interconnected where "port A connect
> to port B". But when the MGW concept was brought into the IP
> world through the Ia interface, this concept does not
> translate well and this issue seems untackled. When I look at
> this definition, it seems it is sugesting some kind of "Layer
> 3 bridging".
>
> It seems to me that _by definition_ the only way to achieve
> that in a real world router is to override its routing table.
> There are many methods to achieve that, but nonenthless seems
> like layering violation.
>
> > Each H.248 Stream endpoint represents basically an "IP host"
> > function. The Stream endpoints within an H.248 Context are
> > interconnected due to the "Context Topology". We got an B2BIH.
> >
>
> I undertand (and kind of like) this concept but it seems to
> work well maybe in a workstation with two interface cards.
> You know, a very simplistic "router".
>
> > The second aspect is how IP address/ports of the hosts are assigned
> > via
> > H.248 LD & RD. You may see already one gap concerning the
> IP SA/SP of
> > the egress flow.
> >
> > The B2BIH mode relates to the interconnection of two IP
> > (bearer) connection endpoints and correspondingly one or more media
> > flows (number of H.248 Streams).
>
> Understood. But again, making this "interconnection" in a
> router means interconnecting at several levels:
>
> 1 - There is the whole IP addressing interconnection issue
> when NAT is in use.
> 2 - There is the interface interconection issue. T1 is in
> interface ip/1/2 and T2 is in interface ip/2/3.
> 3 - If I perform dest (or twice) NAT clearly the next-hop
> that I get from the routing table might indicate an output
> iterface that does not match
> ip/2/3
> 4 - And even without NAT the routing table lookup might give
> me a egress interface that does not match ip/2/3.
>
> So, how can the context topology be guaranteed? Now, imagine
> many (as in tens of thousands) B2BIHs as you put it.
>
> You basically creating an N^2 interconnection mesh inside the
> router to guarantee such behavior. Since a router is not a
> TDM switch, this is (very) hard to achieve. Of course if many
> terminations have ip/1/2 as ingress interface and ip/2/3 as
> egress interface, we set up one "interconnection"
> for many terminations. But it remains to be seen how big
> deployments will look like.
>
> >
> > The IPR mode has two sub-modes: single H.248 Context for IP
> forwarding
> > of
> > a) single IP connection or
> > b) multiple connections.
> >
> > This is then related to the address space (not port space
> because it's
> > IP forwarding, i.e. layer 3 only) behind the
> > H.248 Streams/Terminations. This requires specific handling of the
> > LD/RD, which could be controlled via a new property.
> >
>
> It seems to me (correct me if I'm wrong) that we are still
> missing the interface aspect of the terminations as I
> discuessed above.
>
> Thanks,
>
> Reinaldo
>
> > -Albrecht
> >
> >
> >
> >
> >
> > "Reinaldo Penno"
> >
> >
> > <rpenno@juniper. To:
> > <[email protected]>
> >
> > net> cc:
> > [email protected]
> >
> > Subject: RE:
> > H.248 IP Router Package; Re: [Megaco] Question on
> Interface Routing
> > ...
> > 28.02.2007 17:53
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Wow! You followed up in this? I have to say I'm impressed.
> >
> > Inline....
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]]
> > > Sent: Wednesday, February 28, 2007 6:19 AM
> > > To: Reinaldo Penno
> > > Cc: [email protected]
> > > Subject: H.248 IP Router Package; Re: [Megaco] Question on
> > Interface
> > > Routing ...
> > >
> > >
> > > Reinaldo,
> > >
> > > independent of your question concerning the specific
> TerminationID
> > > syntax in ES 283 018, we did look at the IP router capability:
> > >
> > > > The scenario is a BGF with many input and output interfaces.
> > >
> > > > +----+
> > > > Ifa -| |-ifx
> > > > Ifb -| RT |-ify RT means routing table
> > > > Ibc -| |-ifz
> > > > +----+
> > >
> > > The starting point is an IP-to-IP H.248 Context, and how
> > the "Context"
> > > must behave in order to realize an "IP router"
> > > function. The requirements for such a functions could be firstly
> > > limited to the "IP forwarding process"
> > > itself (see e.g. requirements set given by RFC 1812, § 5.2).
> > >
> > > When you try to realize such a packet forwarding process,
> > it's fairly
> > > obvious that it's not possible to configure the two IP
> > > Terminations/Streams via their LDs/RDs and with existing H.248
> > > elements for such a behaviour.
> >
> > Agreed.
> >
> > > On the other side, introducing e.g. at least two
> > properties (an "IP
> > > forwarding" and an "IP FIB" property), then you may achieve a
> > > behaviour very close to RFC 1812, § 5.2 IMHO.
> > >
> > > ...<snip> (no more details here about such an IP router package
> > > because still in discussion ...)
> >
> > Is there a draft about it?
> >
> > >
> > > -Albrecht
> > >
> > > PS
> > > Is there a requirement for such a function in an H.248 MG?
> > > On the first glance definitely not, because this is more a
> > > "call/session-independent function".
> >
> >
> > Well, I had many discussions about this internally and externally.
> > Reading the current specs I told these people that
> > context/terminations should be independent of routing, but many
> > (external) people disagree with me. My stance is that is fine to
> > disagree as long as there is something in place to tell me how a
> > packet should be routed within a context (and its ingress/egress
> > terminations).
> >
> > It could be:
> >
> > 1. Forwarding/routing takes care of it (this would be the current
> > behavior) based on the existing specs.
> > 2. Some new package that tells me how to make sure packets
> ingress and
> > egress through the desired interfaces (which at some layer
> relate to
> > the terminations like ip/1/32).
> >
> > My problem today is that some people want 1 and others 2.
> The people
> > that want 2 believe that a context by definition create
> some sort of
> > session dependent routing. And since the MGC cannot
> instantiate this
> > (because it does see data packets), it tells the MGW to do it. And
> > creating a context is a implicit way of doing it.
> >
> > >From my perspective I just would like this stuff to be well
> > documented
> > >and
> > specified.
> >
> > > But we may already support session-independent functions with
> > > H.248 ...
> > >
> > > Or, an H.248 AGW/TGW or BGW may be interconnected to an IP
> > edge router
> > > (ER), thus the MG is a front-end element of the ER. But on
> > the other
> > > side you may also embedd the ER function in the MG ... and
> > you may use
> > > an H.248 Context for the ER traffic ... etc etc
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Albrecht
> > >
> > >
> > > SCHWARZ/DE/ALCAT To:
> > > "Reinaldo Penno" <[email protected]>
> > >
> > > EL@ALCATEL cc:
> > > [email protected]
> > >
> > > Subject: Re:
> > > [Megaco] Question on Interface Routing in relation to
> H.248 Profile
> > > 16.10.2006 15:39 for
> > > controlling Border Gateway Functions (BGF) (ETSI ES 283 018)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Reinaldo,
> > >
> > > 1st H.248 vs IP RIB/FIB
> > > There aren't any H.248 capabilities defined so far,
> allowing the
> > > modification of IP RIB/FIB data bases. Thus, H.248 is entirely
> > > decoupled
> > > from IP routing protocols.
> > >
> > > 2nd TerminationID
> > > Don't over-interprete this TerminatinationID structure.
> > The defined
> > > naming convention by ES 283 018 is rather specific because
> > > besides the
> > > basic "identification" function, the syntax is also a)
> overloaded
> > > with
> > > other functions (a1 -> usage of <group>; a2 -> usage of
> > > <interface>);
> > > and b) hierarchical (-> benefit in case of wildcarding).
> > >
> > > The prime purpose behind (a2) is "IP address realm"
> > > indication. Please
> > > note that the ipdc package (H.248.41) was not yet
> available when
> > > ES 283
> > > 018 was defined.
> > > So, the term "interface" could mislead if interpreted as "IP
> > > interface"
> > > (but this isn't the definition by Table 4/ES 283 018).
> > >
> > > - Albrecht
> > >
> > >
> > >
> > >
> > > "Reinaldo Penno"
> > >
> > > <rpenno@juniper. To:
> > > <[email protected]>
> > >
> > > net> cc:
> > >
> > > Subject:
> > > [Megaco] Question
> > > on Interface Routing in relation to H.248 Profile for
> > > 14.10.2006 09:00 controlling
> > > Border Gateway
> > > Functions (BGF) (ETSI ES 283 018)
> > >
> > >
> > >
> > >
> > >
> > > In the specification above (or TS 102 333 for that
> matter) there is
> > > a proposal for the termination ID.
> > >
> > > "5.6.1.1.1 Overview and prose specification The Termination ID
> > > structure shall follow the guidelines of H.248 and shall
> be based on
> > > four fields:
> > > * "ip/<group>/<interface>/<id>"."
> > >
> > > I would like to understand what "interface" means in this context
> > > when related to routing.
> > >
> > > The scenario is a BGF with many input and output interfaces.
> > >
> > > +----+
> > > Ifa -| |-ifx
> > > Ifb -| RT |-ify RT means routing table
> > > Ibc -| |-ifz
> > > +----+
> > >
> > > Packets come from one of the input interfaces (left), a routing
> > > lookup is done, and exit through one of the output interfaces
> > > (right).
> > >
> > > Given the termination ID ip/1/ifx/200 and a gate with source IP
> > > a.b.c.d and destination IP e.f.g.h associated with it,
> which actions
> > > should be done?
> > >
> > > A) One should attach the termination to interface Ifx and
> if packets
> > > go through that interface (and termination) any gate actions are
> > > applied.
> > >
> > > B) One should override the routing table in order to make
> sure that
> > > packets from source a.b.c.d and destination e.f.g.h go
> through Ifx.
> > >
> > >
> > > The two approaches are quite different:
> > >
> > > The first provides a clean separation of Gate Control and
> routing.
> > > You configure routing to make sure the packets you are
> interested on
> > > go through the proper interface (and consequently hit the
> > > termination) when egress/ingress the router.
> > >
> > > The second approach means an overide of the routing table by the
> > > H.248 process. Although possible this represents a protocol layer
> > > violation and it makes me worried about unforseen interaction
> > > between routing protocols and H.248 driven routing table changes.
> > >
> > > What would be the correct interpretation?
> > >
> > > Thanks,
> > >
> > > Reinaldo
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> >
>
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
_______________________________________________
Megaco mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/megaco
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.