MIDCOM Working Group C.Aoun
Internet Draft Nortel Networks
Category: Informational November 2001
Expires on May 2001
Potential Solutions to the
Middle Box discovery problem
<draft-aoun-midcom-discovery-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
Abstract
The Middle Box discovery is one of the problems that the Midcom
architecture has not yet solved. This document proposes a high level
view of potential solutions to the problem as well as interactions
with the Midcom architecture.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1 Introduction.....................................................2
2 Conventions used in this document................................2
3 Used Terminology.................................................2
4 Discovery concepts...............................................3
4.1 Stimuli to send discovery messages.............................4
4.2 Sending the resulting discovery messages.......................5
Internet Draft draft-aoun-midcom-discovery-00.txt November 2001
4.3 Middle Box Discovery Message Sequence..........................5
5 Load Share and reliability issues................................5
5.1 Countering Equal Cost Multi-path issues........................5
5.2 Middle Box fail-over issues....................................5
6 Interaction with the Midcom architecture and issues..............5
7 Security considerations..........................................6
8 References.......................................................6
9 Author's Address.................................................6
10 Intellectual Property Statement.................................6
11 Full Copyright Statement........................................7
1 Introduction
Most of the Middle Box discovery requirements has already been
documented in [Elear]. Several deployment scenarios are documented
in [Caoun].
In this draft proposals will be provided to meet the requirements as
well as other issues that still needs to be solved.
Middle box discovery should take into account peer to peer
applications as well as in the cases where application signaling
goes through application proxies or "application controllers" (ref
to the H323 architecture, SIP when SIP proxies are used and the
Megaco architecture, or other applications where application
signaling proxies are used).
The Middle Box (MB)terminology is aligned with the MIDCOM workgroup
definition.
The MB terminology will probably evolve in time, the draft will be
updated to take into account the new taxonomy.
2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3 Used Terminology
MB: Middle Box- ref to the used terminology in [FRMWRK]
MA: Midcom Agent - ref to the used terminology in [FRMWRK]
MS: Midcom Server- The Midcom interface on the MB, terminology not
yet defined within the Midcom WG
Aoun Informational - Expires May 2002 [Page 2]
Internet Draft draft-aoun-midcom-discovery-00.txt November 2001
AC: Application Client
AS: Application Server- In this document the used terminology covers
the application server function as well as it's host.
DA: Discovery agent- An entity that receives MB discovery results
and forwards it to the required MA. The DA is also responsible for
stimulating the Application Clients to send discovery messages when
applicable
DC: Discovery Client - Entity responsible for sending/receiving
discovery messages
DN: Discovery Node - Function that sits in a Middle Box, updates a
discovery message. In some cases it may terminate and loop back the
discovery messages
AH: Application Host- Computing platform hosting an application
entity
4 Discovery concepts
The MB discovery is based on the following:
-a) The application client will send a discovery message towards the
end application party.
-b) Each traversed MB will modify the discovery message and provide
the actions that are applied to the packet flows.
-c) The destination application party will loop back the discovery
message to the application client
-d)b) is applied again
-f) The application client will then send the discovery message to
the authorized Midcom agents
There are some prerequisites for the solution:
-What is the stimulus for the application client to send the
discovery message?
-To which Midcom agents the resulting discovery message will be sent
? The traversed MBs may not be controlled by the same Midcom agents.
Aoun Informational - Expires May 2002 [Page 3]
Internet Draft draft-aoun-midcom-discovery-00.txt November 2001
++++++++++++++++++++++++++
+ +++++ +
+ +AC + + +++++++++++++++++++++
+ +---+ +++++++ + +++++++++++ +Application Service+
+ +DC + +DN MS+-+---+ Internet+-------+Provider +
+ +++++ +++++++ + + + + +
+ AH1 MB1 + /+++++++++++ + +++++++ +
+ + / | + +MA-DA+ +
+ +/ | + +++++++ +
+ +++++++ + | + AS1 +
+ +DN-MS+/+ | + +
+ +++++++ + | +++++++++++++++++++++
+ MB2 + |
++++++++++++++++++++++++++ |
|
++++++++++++++++++++++++++++++++++
+ +
+ +++++++ +++++++ +++++++ +
+ +DN-MS+ +DN-MS+ +MA-DA+ +
+ +++++++ +++++++ +++++++ +
+ MB3 MB4 AS2 +
+ +
+ +++++ +
+ +AC + +
+ +---+ +
+ +DC + +
+ +++++ +
+ AH2 +
+ +
++++++++++++++++++++++++++++++++++
Figure 1
4.1 Stimuli to send discovery messages
-a) The application controller requests the application client to
send the discovery message
-b) The application client sends the discovery message implicitly to
all application parties or a group of them
The first option could be interesting in case caching capabilities
are provided at the application controller.
Aoun Informational - Expires May 2002 [Page 4]
Internet Draft draft-aoun-midcom-discovery-00.txt November 2001
When caching capabilities are available, the application controller
saves for a period of time the source and destination of application
flows and the associated traversed MB. An intelligent aggregation
scheme could be used either network based or domain based.
Only destinations that were not already reached will require the
application client to send a discovery message.
The second option requires no interaction between the application
controller and the application client, and fits also applications
that doesn't natively use proxies.
It could be realistic to consider cases where caching capabilities
exist on the application client in that case a caching period is
used, thus avoiding useless discovery messages to be sent.
4.2 Sending the resulting discovery messages
Once the discovery result reaches the application client, the
application client has to send it to the adequate Midcom agent who
will need to control the required MBs.
As shown in Figure 1 there maybe 2 (or potentially more) MAs that
will need to control the MBs in order to allow the application to be
successful.
In case the stimulus to send the discovery message is based on an
interaction between the Application Server (or Controller), the
application server will provide via the co-hosted DA (per eg:DA1 in
AS1) , the DAs (DA2 in figure 1) to be notified of the MB discovery
result.
This requires certain means of communicating the address and port on
which the DAs could be reached especially DA2 in figure 1.
These means of communication could potentially be an envelop
parameter in the application layer though some extensions(SIP or as
SDP extensions, H225 or H245 or other protocols depending on the
used application).
4.3 Middle Box Discovery Message Sequence
To be documented
5 Load Share and reliability issues
To be documented
5.1 Countering Equal Cost Multi-path issues
To be documented
5.2 Middle Box fail-over issues
To be documented
6 Interaction with the Midcom architecture and issues
To be documented
Aoun Informational - Expires May 2002 [Page 5]
Internet Draft draft-aoun-midcom-discovery-00.txt November 2001
7 Security considerations
To be documented
8 References
[Caoun] C.Aoun, "Network topology considerations in
the MIDCOM Architectural framework",
Internet draft, draft-aoun-midcom-network-00.txt
[FRMWRK] P.Srisuresh,J.Kuthan, J.Rosenberg," MIDCOM Architecture
& Framework",
Internet draft, draft-ietf-midcom-framework-05.txt
[Elear] E. Lear, "Requirements for Discovering Middleboxes",
Internet draft, draft-lear-middlebox-discovery-
requirements-00.txt
9 Author's Address
Cedric Aoun
Nortel Networks
33 Quai Paul Doumer
92415 Courbevoie Cedex
FRANCE
Email: cedric.aoun@nortelnetworks.com
10 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Aoun Informational - Expires May 2002 [Page 6]
Internet Draft draft-aoun-midcom-discovery-00.txt November 2001
Director.
11 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Aoun Informational - Expires May 2002 [Page 7]