[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
To: CCAMP
Cc: Q.12/15
Note to Q.12/15 participants: within ccamp a discussion has started
to develop an extension to GMPLS supporting connection bandwidth
modification. After a first round of discussion I try to step back
and first discuss the applications and architecture before introducing
solutions. As I believe this is a topic that is also within the scope of
Q.12/15, I am copying this email to Q.12/15.
Let's turn around and enter the next step ...
Looking at the document from an applications level, I got the impression that
the objective of this document is (as reflected in its title) to specify
"connection bandwidth modification" means. I.e.
1) which connection bandwidths can we modify
2) what is the required behaviour during such connection bandwidth modification
3) what needs to be done to modify such connection bandwidth
4) what extensions are required to GMPLS (and ASON) to support this
connection bandwidth modification.
Obvious candidates under item 1) are virtual concatenated VC-n/STS-n/VT-n/ODUk
signals which transport e.g. Ethernet, IP, MPLS packets via GFP encapsulation.
Less obvious candidates under item 1) are contiguous concatenated VC-n/STS-n
signals; by definition in G.707 and T1.105 these VC-n-Xc and STS-nc signals have
a fixed bandwidth.
But if there is a network application which requires that one connection type X
is replaced in-service by another connection type Y, we can analyse the
behaviour and consequential requirements that a ASON/GMPLS [or NMS] like
connection establishment needs to support for this application.
Note - connection types should not be restricted to contiguous
concatenated VC-n/STS-n cases. Within the group of LOVC layer
networks it could be VC-12 into VC-3 (and vice versa). Within
the group of HOVC layer networks it could be VC-4 to VC-4-16c,
VC-4-4c to VC-4-16c, VC-3 to VC-4, etc. The network behaviour in
all case will be the same.
In doing so, we need to tackle several networking scenarios:
A) both path termination points are within the network; the service provided to
the user is a client layer service
B) both path termination points are outside the network; the service provided to
the user is a "connection group" service
C) one path termination point is within the network, while the other path
termination point is outside the network; this is a hybrid or heterogeneous
case.
My proposal is to first focus on the applications and e.g. indicate of which
connection types we want to be able to modify the bandwidth and/or the
connection type.
Regards,
Maarten
Internet-Drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title : GMPLS LSP Bandwidth Modification (LBM) for TDM
> Networks
> Author(s) : E. Mannie, D. Papadimitriou
> Filename : draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
> Pages : 13
> Date : 15-Nov-01
>
> This document defines how GMPLS can be used to dynamically modify
> the bandwidth of a TDM circuit. It focuses first on SONET/SDH and
> will cover G.709 in a next version.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-mannie-ccamp-gmpls-lbm-tdm-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-mannie-ccamp-gmpls-lbm-tdm-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> --------------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID: <20011115154112.I-D@ietf.org>
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard